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ABSTRACT 


The TIME STRIKE optimization model was developed in 1995 for use by the 
cognizant US Air Force agencies to investigate requirements for conventional munitions 
and the feasibility of operational plans based on their availability and current budgets. 
The problem addressed here is: Is the output of TIME STRIKE accurate when compared 
to a simulation? This thesis develops a computer simulation, called SimStrike, which 
models all the same things TIME STRIKE does, using the same data, however with 
randomness used where TIME STRIKE uses expectations. It was found that TIME 
STRIKE and SimStnike produce similar results. 
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1. INTRODUCTION 


A. OPTIMIZING VS. EVALUATIVE MODELS 


Models used in the field of Operations Research can be roughly divided into those 
that find an optimal decision for some problem (optimizing models), and those that 
merely evaluate a given decision (evaluative models). Since their ambitions are higher, 
optimization models generally are forced to make more abstractions and approximations 
in the data they use to achieve their results. These approximations may leave out much 
of the detail otherwise involved in the decision process being modeled, so one is led to 
ask the question: Are the results produced by a certain optimization model being studied 
accurate enough for the approximations used? 

This questions leads to the topic of verification of the optimization model. 
Verification can be accomplished through construction of an evaluative model that 
includes many more of the details left out of the optimization model. These details 
consist of refinement of the approximations used in the optimization model to more 
closely model the situation originally desired in the optimization model. The evaluative 
model can be used to test the optimal solution, results obtained and compared, and 
conclusions drawn. 

This thesis attempts to verify one particular optimizing model, the TIME STRIKE 
munitions optimization model, by constructing a parallel evaluative model called 
SimStnke. 


B. THE TIME STRIKE OPTIMIZATION MODEL 


The linear program (LP) being evaluated by this thesis is the TIME STRIKE 
munitions optimization model (henceforth simply referred to as TIME STRIKE). TIME 
STRIKE was introduced in 1995 for use by various US Air Force agencies to develop 
requirements for conventional munitions, to refine operational plans based on the 
availability of different mixes of munitions, and to assess the effects of procuring 
different types and quantities of munitions [Ref. 1:p. i]. It creates sortie allocations 
across time for a given strike scenario against enemy targets based on things such as the 
type of aircraft, weapons types and loadouts, flight profiles possible, attrition and sortie 
rates, the length of time periods, target regeneration and battle damage assessment 


(BDA), weather, budget, etc. Depending on the desires of the user, TIME STRIKE has 
available five objective functions [Ref. 1:p. 23], but the most useful of these, for the 
purposes of this thesis, is the one maximizing the weighted sum of target-value-destroyed 
(TVD) and time-scripted goals because it gives us a quantitative idea of the “reward” 
gained for the number of targets killed. 

Since TIME STRIKE 1s a large LP, it is forced to make some approximations in 
order to permit it to stay linear. The major approximations made are permitting non- 
integer values for the number of sorties flown and expected kills per sortie (EKS), and . 
using expected values in the place of random quantities. These approximations are 
necessary since TIME STRIKE must remain linear, but they carry with them the potential 
for error. Consider this simple example: Suppose there were 10 targets to be struck and 
there were 6 sorties available, each with an EKS of 1.8. TIME STRIKE would simply 
say you need (10 / 1.8 =) 5.6 sorties out of the 6 available to accomplish the mission, 
assigning the remaining 0.4 sorties to some other target. On the other hand, suppose 
instead that we force kills and sorties flown to be integer valued and random, as they are 
in real life. Using the notation “[no. kills by sortie 1, no. kills by sortie 2,...,no. kills by 
sortie 6]” to represent how many kills each sortie makes against the 10 targets, on any 
particular replication we may get the following results: [2, 2, 2, 2, 2, 0], which is a case 
where the first 5 sorties kill all 10 targets, exactly, so the 6" sortie need do nothing; [1, 2, 
2, 2, 2, 2], which is a case where all 10 targets are killed with the number of kills 
achieved by the first 5 sorties plus 1 of the 2 kills achieved by the 6" sortie, but now there 
is 1 kill left over at the end, which could be applied to another target if there were more; 
[1, 2, 1, 2, 2, 2], which is another case in which all 10 targets are killed, exactly, but this 
time needing the total kills achieved over all 6 sorties in order to do it, instead of just the 
first 5 sorties as in the first case examined; or, if the sorties are particularly unlucky, we 
could get something like [1, 1, 1, 2, 1, 1], a case in which not all of the 10 targets could 
be killed using 6 sorties with the EKS given! But the interesting thing, and also the cause 
of concern, is that TIME STRIKE does not have to face any of these problems which 
may occur in real life. 


cS AIM OF THIS THESIS 


This thesis develops an independent Monte Carlo simulation, called SimStnike, to 
test the TIME STRIKE solution. SimStrike essentially re-flies the sorties output by 


TIME STRIKE, but applying probabilities where TIME STRIKE uses expectations, and 
randomly rounding the non-integer numbers of sorties output by TIME STRIKE to make 
them integer. It accounts for all the same things TIME STRIKE does, i.e., weather, 
BDA, kill goals, etc., and generates the mean TVD for a large number of replications 
along with the standard deviation. The objective is to determine whether the output of 
SimStrike equals the output of TIME STRIKE, on the average. The actual SimStrike 
program listing and directions for use can be found in Appendix A, with a sample output 
provided in Appendix B. 

The remainder of this thesis is organized as follows: Chapter II provides a point 
by point comparison of the major features modeled in TIME STRIKE and SimStrike, 
along with a concise summary of these comparisons tabulated at the end of the chapter. 
Chapter III discusses the results of the thesis obtained and conclusions drawn, and also 
discusses some sources of difference between TIME STRIKE and SimStrike. Chapter I'V 
discusses two areas of future work which might be considered for possible future 
revisions to SimStrike. 





Il. SIMSTRIKE DESCRIPTION 


A. COMPARISON OF TIME STRIKE AND SIMSTRIKE 


SimStnke is a simulation model developed to evaluate the TIME STRIKE 
optimization model. SimStrike re-flies the sorties output by TIME STRIKE, and, using 
the same attrition and expected kills per sortie (EKS) values for each engagement in each 
period, applies probabilities rather than expectations to achieve its results. To achieve 
accurate results, all the same things are modeled which affect the life of a sortie as in 
TIME STRIKE. 

Much of the complication in TIME STRIKE arises from the need to maintain the 
linearity of the optimization model. As a result, some of the quantities which represent 
physical entities, such as sorties, aircraft, and targets, are allowed to assume non-integer 
(also continuous) values, rather than being restricted to integer values, as they should be 
in real life, to represent unit quantities, e.g., 1 sortie, 1 aircraft, and | target vice 0.5 
sorties, 0.6 aircraft, and 1.3 targets. 

For the reader not familiar with TIME STRIKE, some explanations of terms used 
is in order first: 

A period is a fundamental unit of time in TIME STRIKE. In TIME STRIKE, the 
entire time over which the model is run is divided into periods or user-selectable lengths, 
with each of these periods consisting of the same number of fixed-length planning cycles 
[Ref. 1:p. 8]. Planning cycles are more generally referred to as days, the two terms being 
interchangeable in meaning. Many variables and data items used in TIME STRIKE are 
subscripted by period, but not by day. In this thesis, the terms campaign or timed strike 
are also used to represent an entire run of the TIME STRIKE model over time. 

Once TIME STRIKE sorts through the user-provided data, sorties are assigned by 
TIME STRIKE to fly engagements against targets {Ref. 1:p. 1], an engagement being the 
term applied to an encounter between a single sortie and its assigned target(s). A sortie is 
an aircraft taking off, flying strikes against one or more targets, making kills against them 
or perhaps being killed itself, then returning to land if not attrited. Targets are, to put it 
simply, the enemy. Target types refer to a group of targets which are all the same, 1.e., 
all anti-aircraft guns, all tanks, all transport vehicles, etc. Target classes refer to a group 
of target types which all have the same kil/ goals, i.e., the same amount expected to be 
dead or in repair at a certain point in time during the campaign. 


Battle-damage assessment (BDA) is a term used to represent what is thought to be 
the results of a previous day’s strikes. If BDA is perfect, every target killed is known to 
be either dead forever, 1.e., no chance of being repaired or coming back to life, or 
undergoing regeneration, i.e., being repaired. If BDA 1s less than perfect, in addition to 
knowing about dead targets as a result of being killed by sorties, one or more of these 
dead targets may be thought to be still alive, in which case a restrike sortie (henceforth 
simply referred to as a restrike) is assigned to be flown against it the next day. When a 
dead target is misclassified as still being alive, the term mis-BDA is used to apply to this 
situation. The possibility that live targets might be thought dead is modeled in neither 
TIME STRIKE or SimStrike. 


1. Constraints on Sorties 


Before TIME STRIKE can assign sorties to strikes against targets, it must sort 
through the user-provided data to find valid combinations of aircraft, weapons, weapons 
loadouts, delivery tactics (or profiles), time periods, weather states, and target types [Ref. 
1:p. 1]. The number of available sorties is a function of the sortie rate, the attrition rate, 
and the length of the time period [Ref. 1: p. 54]. The sorties are then further constrained 
by the assigned missions which must be performed each period. 

Because TIME STRIKE is an LP, it assumes perfect information with regards to 
restrikes, so it knows from the start exactly how many sorties it must place in each day of 
each period in order to carry out the restrikes. Sorties are proportioned over each day of 
each period to exactly accomplish the restrike missions with no excess left over. Herein 
lies a deviation from reality. In real life, it is not physically possible to assign 1.2 sorties, 
for example, to a restrike mission against some mis-BDA’d target. How does one come 
up with 0.2 sorties as a mission planner? TIME STRIKE allows this, however. 

There is a similar problem for targets. Since target regeneration and kills are 
being optimized in TIME STRIKE to achieve the maximum possible TVD, targets may 
be proportioned as non-integer quantities with non-integer EKS to allow a non-integer 
number of sorties to kill every last one of the targets. The question which anises here 1s: 
How can TIME STRIKE’s advice be taken? Or another way of stating the question: Can 
we be assured of the accuracy of its results given this obvious deviation from reality? 

SimStrike handles this aspect a little differently than TIME STRIKE. The total 
number of sorties an aircraft type actually flies in SimStrike is either the total flown by 


the same aircraft in TIME STRIKE, which is the maximum possible it could fly in the 
period, or some lesser value which could be as a result of losing the maximum number of 
aircraft allowed for the aircraft type in the period, or achieving the kill goal for the target 
type in the period, or simply killing the remainder of the targets. However, since 
SimStrike works exclusively with integers for physical entities, i.e., sorties, targets, and 
aircraft, and therefore also with EKS, target kills are tallied as integers, or whole objects 
of whatever type the targets are, which is the case in reality. So when an aircraft kills a 
target, it does not kill a portion of it, it kills the whole target. Likewise, when sorties are 
flown, they are flown as whole entities, not fractions of sorties. 

The restrictions placed on the flying of sorties in SimStrike are all the same major 
restrictions placed on sorties by TIME STRIKE. 


Z- Distribution of Sorties 


The number of sorties flown by any aircraft against any target by TIME STRIKE 
in any period is uniformly distributed over the period, proportioning a certain number for 
each day of the period to account for all the actions which must be performed, i.e., 
restrikes, strikes against live targets, target regeneration, aircraft attrition, and weather 
aborts. The smallest time unit of resolution for sorties is by period. Also, aircraft do not 
really exist in TIME STRIKE, but rather aircraft sorties. “Aircraft” is merely a term used 
to represent a category for which losses are counted while the LP optimizes under the 
constraint that there is a cap on how many aircraft of each type can be lost, which is 
cumulative over time. 

SimStrike handles this differently and comes closer to reality on the issue of 
sorties and aircraft. SimStrike treats aircraft as actually existing and important entities, 
Separate from the number of sorties they actually fly. Each aircraft is given individual 
attention as it flies its sorties. SimStrike still distributes sorties uniformly over each 
period as TIME STRIKE does, but the main difference is that once the number of sorties 
is distributed uniformly over the period in the simulation, this value is used to produce 
how many sorties per day an aircraft could possibly fly, 1.e., the maximum available for 
the day for the aircraft type. But then SimStrke rounds this non-integer valued quantity 
randomly to an integer value, e.g., 2.3 sorties have a 70 percent chance of being 2 and a 
30 percent chance of being 3 sorties. Over a large number of replications of SimStrike, 
we expect this random rounding to average to the number TIME STRIKE flies. 


3: Expected Kills Per Sortie (EKS) 


EKS is input data to TIME STRIKE, subscripted by aircraft type to which the 
sortie belongs, weapon, target, weapons loadout, weapons delivery profile, and time 
period. EKS can be greater than | for a sortie with multiple weapons, and need not be an 
integer. To describe the problem which exists with this in TIME STRIKE, we go back to 
the simple example mentioned in Chapter I. If EKS 1s 1.8, and there are 10 targets with 6 
sorties available to fly strikes against them, TIME STRIKE will allow (10 / 1.8 =) 5.6 
sorties to fly and exactly kill the 10 targets. In reality, it is not possible to proportion 
physical entities such as targets and sorties 1n this manner. 

EKS is also input data to SimStrike, but SimStnke rounds EKS values randomly, 
as it does sorties, to make them integer. If an aircraft is not attrited and does not 
experience an in-flight weather abort, it is expected to make kills against any remaining 
live targets based on its EKS in SimStrike. Since sorties, targets, and target kills are 
integer valued, an integer number of kills is applied to an integer number of targets. 


4, Attrition Per Sortie 


TIME STRIKE treats attrition as a non-integer valued expectation of aircraft 
losses over time and so proportions a certain number of these losses over each period (see 
Ref. 1 for details). The problem here 1s that aircraft, like targets, are physical entities in 
real life. Either the whole aircraft must be destroyed, or none of it. 

SimStrike maintains this integrality of attrition. Before an aircraft sortie has a 
chance to do anything else in SimStrike, whether it be restrikes or regular strikes against 
live targets, it has a chance to be attrited based on this sortie’s attrition value. If attrited, 
it does not get a chance to kill any targets, 1.e., no “kamikaze” capability, and loses the 
remainder of its sorties for the day. SimStrike then proceeds to the next aircraft in the 
loop, or the next day if this was the last aircraft to fly. Other aircraft must pick up the 
lost aircraft’s mission requirements, as would be the case in reality. If an aircraft is 
attrited, the total number of aircraft of this particular aircraft type 1s decremented by 1. 


5. Kall Goals 


The chosen objective function is based on time-scripted kill goals for each of the 
target classes present. These kill goals in TIME STRIKE are cumulative over time so 


that in at least the last time period of a campaign this value is 1.0. A kill goal of 1.0 
translates into all the targets originally present in the beginning (start of period 1) of this 
particular target type are expected to be dead or in repair (a target must be struck and 
killed before it has a chance to be in repair) by the end of the period of the campaign in 
which the kill goal became 1.0. Aircraft in any period can kill up to the kill goal, but not 
over the goal, with anything killed which was less than the goal being charged as a 
penalty against any TVD reward gained so far. 

This aspect of TIME STRIKE is modeled exactly the same in SimStrike, with the 
only difference being that the actual calculation in SimStrike of the proportion killed, 
found from the number of targets dead or in repair divided by the total number present at 
the very start, has a numerator and denominator which are both integer. This presents the 
possibility of some instances arising where SimStrike cannot exactly meet kill goals in 
some periods. For example, if the kill goal for one period is 0.5, and for the next period 
it is 0.75, and say there are 3 targets, the most kills SimStnke can hope to achieve in the 
first period is | out of the 3 targets, which 1s approximately 0.33 proportion killed and 
under the goal of 0.5. If it killed 2, this would create a proportion of approximately 0.67, 
which is over the goal and so not allowed. Therefore, to make the 2” kill, SimStrike 
would force the sorties to wait until the next period when the kill goal is 0.75, and the 3 
kill would have to wait until a period in which the goal rises to 1.0. 


6. Time Periods and Planning Cycles 


The number of periods and days per period are input data to TIME STRIKE. 
TIME STRIKE places the required number of sorties into each of these days, or planning 
cycles, with the expectation of accomplishing everything planned for that day, 1.e., 
restrikes and regular strikes against live targets. 

The problem is that in reality, a sortie may not be able to accomplish the mission 
is was assigned to perform. Whether because of nature or pure bad luck, the sortie might 
experience an in-flight weather abort, not kill as many targets as thought, or perhaps 
more, or suffer attrition. The randomness of nature is not modeled in TIME STRIKE 
when it comes to sorties. Everything planned may not get accomplished in a day, with 
the result that tomorrow’s sorties may have to pick up some of today’s mission 
objectives. 


The number of periods and days per period are also input to SimStrike. The file 
of solution variables generated by TIME STRIKE after each run of the model, from 
which SimStrike will directly read data for its corresponding run, generates a line of data 
for each engagement run by each aircraft type flying sorties against a particular target 
type. So, for example, if aircraft type 2 flies sorties against target type 5 once in each of 
five periods, there will be a total of five lines of data for this scenario, one for each 
engagement run in each period. The file is organized by period and then by aircraft type 
in each period. This file is in spreadsheet format and is called “TSVTST.CSV”, and is 
placed in the TIME STRIKE “RESULTS” directory after each run of the LP. 

Each line of data in this output file will contain the total number of sorties flown 
over the whole period for the engagement run. Once the number of sorties per day is 
determined by SimStrike, it then simply steps through the days in the period. In each 
day, each surviving aircraft gets to fly sorties at its sortie rate against the targets of the 
target type, first against restrikes, and then until the maximum possible number of sorties 
is flown, the maximum allowed amount of aircraft are lost, all the targets are dead, or the 
kill goal is reached. SimStrike essentially uses nested loops here to accomplish this with 
test conditions for premature exit. This way SimStnke can model reality as close as 
possible by exiting a loop before normal completion when necessary because the 
conditions for exit exist. There is also a varying condition for the start of the aircraft 
loop for each day, based on how many aircraft of the aircraft type have been lost, which 
is continuously updated. 

The important aspect modeled by SimStnke here is that the randomness of nature 
does exist and must be accounted for. While SimStrike reflies TIME STRIKE’s sorties, 
the result may not be the same. For example, the same number of sorties required to 
accomplish restrikes on one day, may not be the number SimStrike uses due to possibly 
having to account for mission objectives which were not accomplished by the sorties on a 
previous day, or fewer sorties may be needed for the restrikes simply because they were 
luckier and conducted more kills per sortie. In summary, the randomness of reality and 
changing mission requirements is modeled in SimStrike. 


de Battle-Damage Assessment and Target Regeneration 


As part of the target data input to TIME STRIKE for each target type, there are 
probability expectations associated with correct BDA and repair proportions for killed 
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targets, the repair proportions having to do with target regeneration. These are dealt with 
as proportions by TIME STRIKE when determining how many targets will be restrikes 
and how many will be in repair in each day of each period, separate from the other 
category which is possible, namely targets which are killed and become dead forever. 
All targets are in one of these three states throughout a run of TIME STRIKE: a restrike 
(mis-BDA‘d), in repair, or dead forever. For a more detailed explanation of the precise 
determining equations associated with placing the targets into these categories, the 
interested reader is referred to Appendix A of Ref. 1. 

The problem with this classification method used by TIME STRIKE is that the 
same proportion of targets struck and killed on any previous day of a period will get into 
one of the three categories mentioned above on a current or future day every time. One 
therefore knows with certainty that for a certain number killed today, what the proportion 
of targets are that must be restruck tomorrow, or what future regeneration will be. Again, 
the randomness of reality is not present here in TIME STRIKE. 

The same data for BDA and target repair/regeneration are used as probabilities 
within SimStrike and are applied across essentially four stages, or phases, which must be 
accomplished, or at least checked to see if the conditions are nght for accomplishment, 
each day of the campaign. These four stages are: (1) Regeneration, executed once each 
day, which represents the probability of targets killed in previous days of regenerating on 
the current day; (2) Restrikes, executed once each day, but potentially by more than one 
aircraft and possibly many sorties, depending upon how many restrikes there are, until all 
the restrikes are complete or all the day’s are sorties flown against them; (3) Regular 
strikes against actual live targets based upon each sorties’ EKS value; and (4) 
Redistribution of kills made by the regular strike phase based on BDA. When actions 
against targets are kept track of in this manner, the same categories possible for targets in 
TIME STRIKE are also modeled in SimStrike. The major difference, however, is that 
the same proportion of killed targets will not be placed into the same category each time. 
Instead, the randomness of reality is accounted for in SimStrike, and it is only possible, 
based on probability, for a killed target to evolve in a certain way throughout any 
particular simulation run, which will not be the same way every time SimStrike ts run. 

For purposes of the discussion of these stages in the subsections which follow, we 
will refer often to Figure 1 below, which is an example of progressing through these 
stages with 40 targets of a particular target type, with the starting condition as shown for 
each of the categories, and the probabilities of following any path as indicated on the 


1] 


arrows. The notation “Pc {2}” means, for example, that with probability Pc, every target 
in the category at the tail of the arrow will move independently to the category at the 
head of the arrow, and in this case 2 targets met the conditions for movement on the 
arrow; when just a number in brackets is present, with no associated probability listed 
next to it, e.g., “{3}”, this means that all targets in the category at the tail move to the 
category at the head of the arrow. 


a. Target Categories 


The six target categories shown in Figure 1, which are also what the 
variable names are called in SimStrike, are defined below: 


(1) LiveN Targets. LiveN targets are the number of live targets 
that are not restrikeable. These represent all the actual live targets, recognizable as alive 
by the aircraft flying sorties against them. At the start of a replication of a SimStrike run, 
this variable is initialized to the total number of targets of the target types present as read 
in from the data input file. 


(2) DeadN Targets. DeadN targets are the number of dead 
targets that are not restrikeable. These are targets which are dead forever, 1.e., will not 
regenerate or be subject to BDA. Once a target gets into this category, it stays there 


throughout the remainder of the SimStrike replication run. 


(3) RegenN Targets. RegenN targets are the number of 
repairable targets that have previously been killed but placed into repair, and are not 


restrikeable. 
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... start Day 


LIVEN DEADN REGENN LIVER DEADR REGENR 
Starting 20 10 5 0 3 2 
Condition 
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v 
NPr {0} 
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...9orties Flown 

Restrike Japs 14 4 0 0 0 
... sorties Flown 

Regular 19 14 4 v 0 0 
Strike 


Now have 37 targets with 3 kills which must be redistributed 





Redistr. 19 15 - 0 ] ] 
...End Day ®» Now go to next day and start process over again... 


Figure 1 - The four stages associated with sorties in each day of a SimStrike period. 


(4) LiveR Targets. LiveR targets are the number of live targets 
that are restrikeable. This category represents the number of targets which have just 
come out of repair in the planning cycle but may be restruck and returned to repair 


(become a RegenN target), or become dead forever (a DeadN target). 


(5) DeadR Targets. DeadR targets are the number of dead targets 
that are restrikeable. These are the targets that were actually killed in a previous 
planning cycle but were not repairable, 1.e., dead forever, but were mis-BDA’d and are 
believed to be still alive. The only possibility for these targets are to become dead 


forever (DeadN) when restruck. 


(6) RegenR Targets. RegenR targets are the number of 
repairable targets that are restrikeable. These targets may regenerate and become a 
LiveR target, or remain as a RegenR target through the regeneration phase, and then any 
remaining RegenR targets may become RegenN or DeadN targets during the restrike 
phase. 


b. Comparison of SimStrike Target Categories with TIME STRIKE 


TIME STRIKE does not explicitly use the target categories as shown in 
Figure 1 and described above, but allows for each of the same six possibilities for the 
state of a target at any given time through the BDA equations it uses to calculate the 
proportion of targets existing in each of the states over time (see Appendix A of Ref. 1). 
These six categories in SimStrike, however, along with the associated probabilities 
shown on the arrows in Figure 1, and defined below, model the same aspects of the BDA 
equations used in TIME STRIKE, but probabilistically. 


(1) Probability a target regenerates in the next planning cycle, 
Pc. This probability is associated only with the RegenN and RegenR categories of 


1 / Repair Time 


targets in SimStrike and 1s calculated from, Pc = 1 -e€ , where “Repair Time” 
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is input data for both TIME STRIKE and SimSinke representing the amount of time in 
days required for repair of a killed target of a particular target type. The probability NPc 
is merely the quantity (1 - Pc). 


During the regeneration phase at the start of each day, this is the 
probability used to determine how targets in the RegenN and RegenR categories will be 


distributed as shown by the arrows in Figure 1. 


(2) Probability a target is repairable after a strike, Pr. This 
probability is used in two of the four phases which sorties experience each day, the 
restrike and redistribution of kills phases. The most obvious application is within the 
redistribution of kills phase where, after the BDA of the targets just killed has been 
determined, for each of the groups of good and mis-BDA’d targets, this probability is 
used to determine which ones will go into a regeneration, or repair category, and which 


will go into a dead category. 


The other application, which is not so obvious but still modeled 
within TIME STRIKE, is in the restrike phase. If the category chosen from which the 
restrikes will come, which is randomly decided in SimStrike, is from the DeadR 
category, we do not have to worry about this probability, or any probability for that 
matter because these targets will, with probability 1.0, become dead forever, or DeadN, 
when they are restruck. However, if the category chosen from which restrikes will come 


is either LiveR or RegenR, the probability Pr applies. 


Pr is set equal to the repair proportion read in for each target type, 
which is data to both TIME STRIKE and SimStnke. When restrikes are chosen from the 
LiveR or RegenR category, the restruck targets are distnbuted as shown in Figure 1 for 
the probability Pr. NPr is merely the quantity (1 - NPr). 
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(3) Probability of correct BDA for a target, B. This probability 
only exists in the decision process within the redistribution of kills phase. It is simply 
used to decide which of the targets just killed in the regular strike phase will have correct 
BDA, and which will be mis-BDA’d (NB = I - B), 1.e., thought to be still alive, and must 
therefore be restruck the next day, even though they were actually killed. Of these two 
groups, it is further decided whether they will also become dead or in repair as shown in 


Figure 1. 


ra Description of the Four Stages associated with Sorties 


“Stages”, and “Phases”, are identical in Figure 1. These stages are passed 
through in the same order every day of a SimStrike run: (1) Regeneration, (2) Restrike, 
(3) Regular Strike, (4) Redistribution of Kills. 

It 1s important to remember that any numbers in “{e}” in Figure 1 
represent the number of targets moving along that arrow as a result of execution of that 
stage. The arrows point to where the targets are moving, and Figure | is only an example 
of what may happen in one day for a case where there are 40 targets to start with. Also, 
throughout a SimStnke run, it is always true that (LiveN + DeadN + RegenN + LiveR + 
DeadR + RegenR = Total number of targets starting the SimStrke run). In the example 
in Figure 1, this total would always be 40. 

The following is a description of what happens in each of these stages: 


(1) Regeneration Stage. This stage in SimStnke is within the 
days loop but outside of the aircraft loop so it is only executed once per day. This stage 
is executed independent of aircraft and their sorties, only operating on any targets in the 
RegenN or RegenR categories. As shown in Figure 1, this stage marks the beginning of a 
new day and represents the first thing which must be done, or decided by SimStrike for a 
new day, the initial conditions of which are the results of the previous day’s actions. 
This is meant to model the same lag in detection of regenerated targets by one planning 
cycle that TIME STRIKE does, preventing it from acting on new information until the 
next day [Ref. I:p. 11]. The number of targets in the RegenN category that move to the 
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LiveN category is determined from a Binomial(RegenN,Pc) probability (see Ref. 2 or any 
probability and statistics textbook for a discussion of Binomial probabilities), with the 
remainder left in the RegenN category. Likewise, the number in the RegenR category 
which will move to the LiveR category is determined from a Binomial(RegenR,Pc) 


probability, with the remainder left in the RegenR category. 


(2) Restrike Stage. This and the remainder of the stages are 
within the aircraft loop because although they are only executed once per day, some or 
all of the aircraft of the aircraft type involved in the strike may fly sorties against the 
target type. Aircraft flying sorties against restrikes are still subject to attrition and in- 
flight weather aborts just as they are for regular strikes against live targets. As with 
regular strikes, if an aircraft is not attrited and does not experience an in-flight weather 
abort, it is expected to make “kills” against these restrikes. All restrikes for the target 
type must be done before any aircraft of any type is allowed to fly sorties against actual 
live targets of the target type, just as is done in TIME STRIKE. 


Restrikes are accumulated from the Regular Strike phase of the 
previous day, or potentially carried over from more than one day ago. The latter case 
would mean all the aircraft fly their sorties against restrikes but cannot quite finish them 
all off and so do not proceed to the regular strike stage, in which case restrikes may 


accumulate for more than one day. 


When sorties are making restrikes, there are three categories from 
which the accounting for the “kills” against them can come: LiveR, DeadR, or RegenR. 
SimStrike assumes each restrike is against a target randomly chosen from the total of all 
these categories. Binomial(category,Pr) probabilities apply to the distribution of kills for 
the LiveR and RegenR categories, with the targets in the DeadR category always going to 
the DeadN category when they are struck, as shown in Figure 1. 
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Aircraft will continue to fly sorties against the target type’s 
restrikes until all are restruck (LiveR, DeadR, and RegenR all equal to zero), the 
maximum number of sorties possible are flown, or the maximum allowed amount of 
aircraft are lost due to attrition. The exit conditions of the restrike stage will then 


contribute to the initial conditions of the regular strike stage. 


(3) Regular Strike Stage. This stage involves only those targets 
in the LiveN category. When restrikes are complete, and if there are aircraft sorties 
remaining to be flown, then, if these aircraft are not attnited and do not experience an in- 
flight weather abort, they are expected to make kills against actual live targets based on 
their EKS values. When the aircraft gets to this point within this stage, there are no 
longer any probabilities associated with the outcome of the kills 1t will make, as shown in 
Figure 1, with the exception of the random rounding of the sortie’s EKS value to make it 


integer. 


The number of kills this sortie will make 1s calculated and then 
program flow immediately passes to the redistribution stage to distribute these kills 


amongst the possible categories as shown in Figure 1. 


(4) Redistribution of Kills Stage. The kills are distributed as 
they are made amongst the possible categories to which they can go based on the 
probabilities B, NB, Pr, and NPr as shown in Figure |. Thus, the redistribution stage 
actually occurs successively right after the regular strike stage for each sortie, but a 
boolean condition prevents the restrike stage from being executed more than once per 


day, even though it is within the aircraft loop. 


When the maximum number of sorties have been flown, the 
maximum number of aircraft has been lost, all the targets have been killed, or the kill 


goal has been achieved, the current day ends. 
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8. Calculation of the Objective Function Value 


In TIME STRIKE, two general quantities are calculated to be used in the overall 
objective function value calculation: the TVD reward gained, and the penalties for not 
meeting the time-scripted kill goals in each period, if any [Ref. 1:p. 24]. TIME STRIKE 
takes credit in each period for the target value of each target for the current period, times 
the total number of each target currently dead or in repair. Penalties against TVD gained 
are calculated from a set of known kill goals, which are data to TIME STRIKE and are 
cumulative over time. The kill goals constrain the total targets dead or in repair through 
the end of a particular period to a proportion of the total targets originally present at the 
start of the campaign. TIME STRIKE ts allowed to kill targets up to the goal, but not 
over the goal in each period. Any difference below the goal is taxed against TVD by 
summing the weighted proportional differences over all periods for all target types. 

SimStrike calculates the same objective function as TIME STRIKE. The 
simulation routine within SimStnke 1s run once for each of TIME STRIKE’s sortie 
variables obtained from the output data file “TSVTST.CSV”. At the end of a run, just 
before program flow passes back to the main program within SimStrike, the TVD reward 
is collected by multiplying the target value applying to the current period for the current 
target type by the quantity (DeadN + RegenN + DeadR + RegenR), which represents all 
the targets of the target type dead or in repair at this point in time. 


B. SUMMARY OF COMPARISONS OF TIME STRIKE AND SIMSTRIKE 


Table 1 on the following page provides a summary of the comparisons made 
between TIME STRIKE and SimStrike in section A. 
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Category ] TIME STRIKE | SimStrike 


Constraints on Sorties Fractional sorties and Integer sorties and targets 
targets 

Distribution of Sorties Deterministically uniform | Randomly uniform over 
over periods periods 


EKS Fractional numbers of kills | Integer numbers of kills 


Attrition Per Sortie Fractional losses of Integer losses of aircraft 
“aircraft” 


Kill Goals Cumulative proportion of Cumulative proportion of 
original number of targets _| original number of targets 
expected to be dead expected to be dead 

Time Periods and Planning }{ Periods and days; mis- Periods and days; mis- 


Cycles BDA’d targets become BDA‘d targets become 
restrikes the next day with =| restnkes the next day with 
all restrikes taken care of on | the possibility existing that 
the day they are assigned not all restrikes will be 

taken care of on the day 

they are assigned, 1.e., may 





Carry over one more da 


BDA and Target Treated as proportions Treated as probabilities 
Regeneration 


Calculation of the Objective || TVD taxed by penalties for | TVD taxed by penalties for 
Function Value not meeting kill goals not meeting kill goals 


Table 1 - Comparison Summary of TIME STRIKE and SimStrike 
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If. RESULTS 


A. RESULTS 


Two simplifications were made in SimStrike for the purposes of this thesis. The 
first was to make all aircraft arrive on the first day of the campaign. For this, the data 
files were matched to have the total amount of aircraft of each aircraft type simply be 
read in as being there the very first day of the first period. The second was to run TIME 
STRIKE and SimStrike over only one Major Regional Conflict (MRC). Therefore, the 
attribute of allowing aircraft swings between two MRCs was not modeled. 

A model data set was provided by Maj. Kirk Yost, USAF, (TIME STRIKE’s 
author) for an example Air Force simple strike scenario. The scenario the input data sets 
to TIME STRIKE represent are groups of known targets and their locations at various 
distances from the sortie origination point, a given set of aircraft, weapons, crew 
qualifications, weather forecast, kill goals, etc., meant to represent just one of many 
possible MRC’s. The data set was unclassified, but representative of realistic data in use. 
For this data set, TIME STRIKE produced an answer of 4,140,022 “points”. Using the 
same data set, after 1000 replications, SimStrike produced an (mean) answer of 
4,010,561 points with a (sample) standard deviation of 245,326. The answers produced 
at each replication of SimStrike are plotted on a histogram in Figure 2 on the next page. 
Assuming TIME STRIKE is producing the true mean and SimStnke is producing the 
sample mean and standard deviation for a large sample (large number of replications), 
the Sample t-Test [Ref. 2:p. 322] with a null hypothesis of H,: » = p, and corresponding 
alternative hypothesis H,: p # u, produced a test statistic value of 16.7. This is enough 
to reject the hypothesis that TIME STRIKE and SimStrike produce the same results at 
virtually any level of confidence desired. 

The question now 1s: What does this mean for TIME STRIKE? Does it lead one 
to conclude that the model is no good? The answer to this last question is emphatically 
NO. After all, the objective functions differ by only 1%. TIME STRIKE’s problems are 
incurable, but not serious, and these results only lead to the need to study the way the LP 
models reality a little closer. 
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Figure 2 - SimStrike Objective Function Value Histogram for 1000 Replications 
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B. SOURCES OF DIFFERENCE 


This section will discuss some explanations of why TIME STRIKE and SimStrike 
results differ. 


1G Period Transitions and Restrikes 


In TIME STRIKE, within the same period, any targets killed today which carry 
over to tomorrow as restrikes due to bad BDA, must be restruck before any further live 
targets of the same target type are allowed to be struck. A problem occurs when the 
restrikes carry over from the last day of one period to the first day of the next period, in 
which case the model does not allow sorties to be flown against them due to the 
problems of mathematical complexity at the time the model was developed. Instead, it 
discounts TVD by the number of restrikes which would have to be done, were they 
allowed to be, times the target value of this target type for the new period. The restrikes 
are then essentially discarded and regular sorties are flown against live targets of the 
target type. To reiterate, this only occurs at period transitions within TIME STRIKE. 

In SimStrike, period transitions are transparent as far as restrikes are concerned. 
If restrikes carry over from the last day of one period to the first day of the next period, 
they are restruck first, as they would be in any other day, before sorties are flown against 
actual live targets of the target type. SimStnke essentially views all the periods as 
actually just a string of days, which happen to transition through pends, only using the 
current period number to determine which data gets manipulated with other variables, 
e.g., target values, kill goals, etc. SimStnke merely lets restrikes randomly play out over 
time. This accounts for only a small numerical difference between the results of 
SimStrike and TIME STRIKE as shown in Table 2 below, and only a slight difference 
from the result SimStrike produced as noted in Section A above. 

Also shown in Table 2 is a sensitivity analysis for four other special cases 
performed to compare results between SimStrike and TIME STRIKE. As can be seen, 
the results all closely agree quantitatively, except for a target rich environment, Case 4, 
which is explained further in the next subsection below. The scaling factor for a target 
rich environment is the reduction from the base case, 1.0, which is no change in the 
original number of aircraft present, i.e., not target rich or target poor. For example, the 
scaling factor shown in Table 2 for Case 4 means the base case, 1.0, divided by 2, or half 
the number of aircraft originally present, to produce a scaling factor of (1.0 / 2 =) 0.5. 
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TIME STRIKE SimStrike 
Objective Function | Objective Function SimStrike 


Value Value Standard Deviation 


4,140,022 4,000,164 236,407 


4,235,479 4,020,925 201,105 


689,913 539,358 33,881 


4,115,600 3,774,709 278,424 


4,162,430 4,125,762 277,408 


Case 


(1) No restrike 
Carry-over at period 














transitions 
2) Perfect BDA 
(3) All target values 
set to 4.0 
(4) Target rich 


environment for 






scaling factor of 0.5 


(5) Target poor 


environment 


Table 2 - Sensitivity Analysis 


Ve Target Rich Environment 


Target rich environments were created by reducing the number of aircraft present 
to fly against the same number of targets in the original data set. The case shown in 
Table 2 is for half the original number of aircraft, or a scaling factor of 0.5. Several 
target rich environments were produced and results plotted in Figure 3 on the next page 
for TIME STRIKE and SimStrike. A scaling factor of 1.0 means the original number of 
aircraft present, or the base case. Any scaling factor less than 1.0 is a target rich 
environment, and anything above 1.0 would be target poor, which is not shown in Figure 
3 because TIME STRIKE and SimStrike closely agree quantitatively for a scaling factor 
of 1.0 and above. 
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Figure 3 - Comparison of TIME STRIKE and SimStrike for a Target Rich 
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Figure 3 shows a noticeable difference between results for TIME STRIKE and 
SimStnke for a target rich environment, but then rapidly approaching one another as a 
scaling factor of 1.0 1s approached. The data used to plot Figure 3 is shown in Table 3 
below. Although not shown in Figure 3, the data for the target poor environment case of 
a scaling factor of 2.0 1s shown in Table 3 for comparison purposes. 


Scaling Factor 













Value 


SimStrike 


Standard Deviation 


0 0 0 

1,338,622 1,019,691 100,006 
2,362,772 2,217,805 89,532 
2,762,169 2,612,735 75,176 
3,390,982 3,319,477 74,465 
3,823,302 3,449,200 58,398 
4,066,308 3,798,582 105,531 
4,115,600 3,774,709 278,424 
4,140,022 4,010,561 245,326 
4,162,430 4,125,762 277,408 


Table 3 - Target Rich Environment Data for Figure 3 


Ab Proportioning of Sorties Over Time and Restrikes 


When TIME STRIKE decides what sorties will be flown 1n a campaign, it looks 
at its constraints and data, and then places a certain number of sorties to be flown by the 
various aircraft against the various targets in every day of every period. A portion of the 
sorties which have been selected to fly in every day of the campaign are there to account 
for restrikes. The extra number within the total allotted due to the restrike requirement is 
to exactly account for these restrikes, i.e., all the restrikes will be taken care of in their 
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entirety each day before the aircraft go on to fly sorties against live targets, and no 
restrikes will carry over to the next day. 

SimStrike does not recognize a certain number of the sorties to be flown on any 
particular day as being present solely for restrike purposes, as TIME STRIKE does. How 
many sorties will be needed to clear the restrikes is decided randomly, so it is possible 
that more or less sorties, 1f any, will be dedicated to restrikes than were in TIME STRIKE 
on any given day of the campaign. 

The potential source of difference here lies in the possibility that when SimStrike 
is doing restrikes, 1f a small number of aircraft are flying sorties at low sortie rates and 
low EKS values against the restrikes, not all the restrikes may be cleared in a day. 
Therefore, there may be some restrikes which carry over to the next day, which could 
lead to more or less being done on some particular day in SimStrike than TIME STRIKE 
would expect for its circumstances. This situation arises because the new day’s restrikes 
in SimStnike would now include carry over restrikes from yesterday which were not 
completed. 

Experience with SimStrike, however, does show that most restrikes are done on 
the day they are encountered, and very few carry over to the next day. For example, if we 
look at the detailed statistical output for the first replication at the beginning of the base 
case output for SimStrike contained in Appendix B, the total number of restrikes which 
carry over from the last day of each period to the first day of the next period is shown in 
Table 2 below. 


Period -over Restrikes 





Z 36 
3 34 
4 4] 
5 29 


Table 4 - Example of Carry-Over Restrikes 
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The carry-over restrikes shown in Table 2 are the totals over all target types in 
each period, and when compared to the total targets of each type present and the total 
dead or in repair each period, the quantities in Table 2 represent well less than 1% of 
these totals. 


¢: CONCLUSIONS 


The differing results between SimStrike and TIME STRIKE are cause to examine 
closer TIME STRIKE’s modeling of reality. Although many estimates are being made, 
perhaps within the BDA equations in the optimization model, these hurdles are not 
insurmountable. The objective function values obtained by TIME STRIKE and 
SimStrike are similar, although the hypothesis they produce the same expected measure 
of effectiveness (MOE) is rejected. The sources of difference discussed in the previous 
section do not contribute significantly to the differing results, so the source of deviation 
must lie elsewhere. 

SimStrike was developed to model all the same things TIME STRIKE does, but 
to use probabilities where TIME STRIKE uses expectations. As shown in Table 1 in 
Chapter II, these probabilities were applied at the appropriate places where reality comes 
into play, while the integnty of other factors such as the distribution of sorties over 
periods, kill goals, and the calculation of the objective function value, were maintained 
exactly the same as TIME STRIKE. Therefore, somewhere within the many expectations 
used by TIME STRIKE for the purposes of optimization lies one or more approximations 
which may be too abstract. Thus, it is a matter of identifying and refining one or more of 
these expectations which Is in order. 
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IV. FUTURE WORK 


A. WEATHER 


TIME STRIKE currently assumes that weather is known before profiles are 
selected for given aircraft types [Ref. 1:p. 12]. Expectations for six weather states are 
read in as data and correlated with what weapons and tactics can be used for a given 
weather state against a certain target type, then the sorties are assigned. SimStrike uses 
the same expectations as data, then as a probability comparison to a uniform random 
number to see if there will be an aircraft sortie weather abort given the present weather 
state. TIME STRIKE and SimStnke are therefore both relying on the accuracy of the 
same forecast, and therefore both miss the true randomness of nature. 

A better model might be one in which weather is decided randomly each day. Of 
course linear programs do not have random number generators, so this is not an option 
for TIME STRIKE. But one could take SimStrike a step further (it would actually be a 
giant step in this case) and randomly decide weather on each day, and then pick the 
weapons and tactics on a day-by-day basis for available aircraft to fly sorties against 
targets. However, this kind of simulation would not read data in from the solution 
variables produced by a run of TIME STRIKE, it instead would be generating its own 
sorties over time, so it would therefore be a re-work of SimStrike. 


B. PROBABILITY DISTRIBUTION FOR RANDOM ROUNDING 


Currently, SimStrike uses a uniform random number to determine whether a non- 
integer value gets rounded up or down. Using this consistently where rounding is 
required means that, over a large number of replications, these rounded values average 
out to the non-integer value from TIME STRIKE. This rounding arises for sorties flown, 
EKS, and sortie rate values in SimStrike, a uniform random number being used to ensure 
SimStrike models TIME STRIKE as closely as possible. 

One might argue that this rounding may be better done using a Poisson 
distribution if the number of sorties flown as read from the file of solution variables 
produced by TIME STRIKE are viewed as events occurring over fixed time intervals. In 
this case, since the outcome is based on the total number of draws, or sortie occurrences, 
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to be made over time, the rounded values will not necessarily average out as closely to 
what their original non-integer values were as in the uniform random number case above. 
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APPENDIX A: PROGRAM LISTING AND DIRECTIONS FOR USE 


SimStnike 1s coded in Turbo Pascal for Windows, but is compatible with Turbo 
Pascal for DOS as long as the “Uses WinCrt;” code line is commented out. SimStrike 
uses four input data files and produces one output file which can be opened by almost 
any spreadsheet application, however, our preference is Excel. Only one of the four data 
input files is “homemade” because it contains only selective data required by SimStrike 
which is contained in a much, much larger data input file to TIME STRIKE. The other 
three data input files are merely the same ones used by TIME STRIKE, but with the 
filename extension changed to make it useable by the Turbo Pascal compiler. 

For the output, the user has several options as annotated in the comments within 
the main program part of SimStrike. The output can take many forms, very limited or 
detailed based on what the user comments out or keeps in, but is set up to provide the 
most detailed statistics as listed in this Appendix, with an example output contained in 
Appendix B. The very last three lines of any output, however, will be the number of 
replications ran, the mean objective function value, and the standard deviation if the 
number of replications is greater that or equal to 30. 

Before running the program, there is a note in its comments at the very beginning 
of the program listing which must be heeded. Since the data segment created by the 
program is very large, the default values for the stack and heap sizes for the Turbo Pascal 
compiler are not of sufficient sizes. These should be manually set to 15,000 bytes each 
by the user before the program 1s compiled, or a stack overflow runtime error will result. 
Setting the stack and heap sizes too large, however, may prevent compilation if the 
machine does not have enough memory to support it. A typical 486 or Pentium PC with 
16MB of RAM will do a quick job of running SimStrike with a compiler stack and heap 
size of 15,000 bytes. 

SimStrike has been designed to be as robust as possible, but it is assumed that 
only a user somewhat knowledgeable of TIME STRIKE will actually be using it, so it 1s 
biased toward that end. Most terms used in SimStnike are those which would normally 
be known by those familiar with TIME STRIKE, and the detailed comments in the 
beginning and throughout the program listing are geared towards these users. Also, there 
is not complete data input error trapping, especially associated with some of the more 
larger data input files, because it is assumed only meaningful data will be used, and 
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would also cause an especially excessive additional amount of code to be added to an 
already very long program. 

This Appendix will now describe in detail how to use SimStrike, the program 
listing for which can be found on the following pages. It may be helpful to refer to the 
program listing as these directions are read. To reinforce the directions, the data input 
file “sim2in.dat”, which is used by SimStrike, but not by TIME STRIKE, is presented 
after the program listing. This input file contains specific data from one of the larger 
data files used by TIME STRIKE. 


Conditions to be set prior to executing the directions for running SimStrike: 


e Set the STACK and HEAP sizes of the Turbo Pascal compiler on the machine 
on which SimStnke is to be run to 15,000 bytes (minimum) each. This is 
needed so the data segment created by SimStrike 1s accepted by the compiler, 
otherwise there will be a stack overflow runtime error. Note: Do not go 
overboard with the STACK and HEAP sizes. Setting them too large will 
prevent the compiler from compiling if the machine the program is run on 
does not have enough memory to support it. 


e Ensure the simulation program and the data files it will use all reside in the 
same directory. The output file will also be placed in this directory when it is 
created. Set the Turbo Pascal default directory to this directory if not already 
done so. 


e Ensure the data input file “sim2in.dat’” in SimStrike’s directory contains the 
same requisite data (see the listing later in this Appendix for details) as 
“stand13.dat” in TIME STRIKE’s “Data” directory. 


e Ensure the target values in the data input file “tgtval22.txt” in TIME 
STRIKE’s “Data” directory and in the data input file “tgtval22.dat” in 
SimStrike’s directory are the same. The “tgtval22.dat” file used by SimStrike 
may be a copy of “tgtval22.txt” used by TIME STRIKE, with file extension 
changed, except that the “MRC1.” preceding each target type number must be 
deleted before it 1s useable as an input file to SimStrike. The same 
requirements apply to the files “tgtdat22.txt” in TIME STRIKE’s “Data” 
directory and “tgtdat22.dat” in SimStrike’s directory, also ensuring all the 
target data is the same for both. 


e Copy the file “tsvtst.csv’ from TIME STRIKE’s “Results” directory to the 


directory the simulation program is in. Change its file extension to “.dat”, and 
then open it with Microsoft Wordpad (a common application on any PC with 
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any version of Windows installed) and remove the text lines and extra blank 
lines preceding each set of numerical data to which they apply. If there are 
any extra blank lines at the end of the file, remove these also. Note: Another 
application can be used to open and edit “tsvtst.dat” as long as the font is set 
to “Courier” or “Courier New’. In either case, make sure to save it when 
done editing. 


Remember that there 1s no data input error trapping, so one must pay attention to 


the above directions and make sure they are followed exactly so input errors or bad 


results do not occur. In most cases it 1s simply a matter of copying files from one 
directory to the next, then just changing the file extension (and removing the “MRC1.” 
text In some Cases). 


Directions for running SimStrike: 


If the program will be run via the DOS version of Pascal, then the code line 
“Uses WinCrt;” must be commented out. This is the first line of program 
code after the initial comments. 


Scroll down in the program listing to the constant declarations (code line 
“Const’’). Here you may set the values of five of the constants used in the 
program: the number of replications, the seed for the random number 
generator, and three replication output instances. Note: The random number 
generator does not have to be seeded. The “Randomize;” code line given in 
the main program part can be used instead, which seeds the random number 
generator with the system clock on the machine SimStrike is run on, and the 
“RandSeed” code line can be commented out. When using the Randomize 
function, however, the string of random numbers produced will not be 
repeated each time SimStnike is ran. When setting a replication output 
instance remember that these will be the instances out of all the replications 
which will be output in detailed statistical tabular format. If only one 
replication, or none, of these instances are desired to be included in the 
output, set the values in the “Const” declaration section to instances which are 
higher than the number of replications which are being ran. 


Now scroll down to the main program part of SimStrike. Here will be found 
several comment blocks, which, among other things, explain how to change 
the output into other formats depending on one’s desire. SimStnke “comes 
from the factory”, per se, with the most detailed and useful output form, 
outputting one statistical tabular replication instance, along with objective 
function values for each replication, and the final statistics, all in Microsoft 
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Excel spreadsheet format. The output file which is created 1s “sim2out.csv”, 
and can potentially be opened by other spreadsheet applications which accept 
this format. 


At this point SimStnke is ready to be run. Be advised that a previous version of 
“sim2out.dat”, which may be open for viewing in a spreadsheet application, must be 
closed before actually running SimStrike because a runtime error will occur due to the 
inability of SimStnike to write to the output file if it is still open. Also, there are detailed 
comments at the beginning and throughout the program listing which provide significant 
help in interpreting sections of program code and aid in getting it set up for running. 

The program listing starts on the next page, and the listing for “sim2in.dat” can be 
found on the pages immediately following the program listing. 
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Program Simulation2; 


{ 


Programmer: 


Thesis Advisor: 


Revision Date: 


Purpose: 


Notes: 


John J. Kosina 


Prof. Alan R. Washburn 
Operations Research Department 
Naval Postgraduate School, Monterey, CA 


T/is/2) 


Monte Carlo simulation used to conduct error analysis 
on the Air Force's Time Strike Optimization model 
using some modifications to certain variables and data 
(explained below) used in objective function 4 to 
maximize the weighted sum of TVD. GAMS model is run 
in parallel to compare outputs. 


(i) 


(2) 


(3) 


"sim2in.dat” data input file must contain data in the form: 


lst line: 
TVDWGT, GOALWGT 


2nd line: 
number of periods, number of days in each period 


3rdq line: 
number of aircraft types 


Each of following lines up to the total number of AIRCRAFT 
TYPES, one line per aircraft type: 
aircraft type, number of aircraft for aircraft type starting, 
max loss allowed for the aircraft type, sortie rate (sorties 
per aircraft per day) for the aircraft type 


Next line: 
number of target classes 


Each of following lines up to the total number of TARGET CLASSES, 
one line per target class: 
proportion of targets in target class to be killed to achieve 
the goal for each time period 


Each of following lines up to the total number of TARGET CLASSES, 
one line per target class: 
objective function penalty for not meeting the time-scripted 
goal for the target class (as given in the data block just 
prior to this one) by the end of the period for each time period 


Each of following lines up to the total number of TARGET CLASSES, 
one line per target class: 
targets which belong to the target class 


"tgtval22.dat" data input file is target values for each target type 
by period in which they are killed. These values may be randomly 
generated for all the target types as long as the same data values 
are used for both the GAMS model and simulation runs. 


"tgtdat22.dat" data input file is target data by distance 

band (used to obtain total targets of each type), bda probability, 
repair time, percent of killed targets that regenerate. Target 
Elements are not used by the simulation. This is the same data as 
those used by the GAMS model except that target data by distance 
band must be integer (therefore will be the same for both GAMS 
model and simulation), and repair times must be integer (also same 
For BOE) < 


"tsvtst.dat"™ data input file is conversion of GAMS model output 
file "tsvtst.csv”. This file contains the solution data and variable 
values for the last run of the GAMS model. 


When the GAMS model is run for a certain data set, the "tsvtst.csv” 
file from the GAMS model Results directory should be 

copied to the directory containing the simulation and renamed to 
"tsvtst.dat". After deleting the short text lines and any extra 
blank lines at the beginning of the long lines of numerical data for 
each period, data may be used as is. Even though they are real 
values seperated by commas, which is not a proper data format for 
Turbo Pascal, this simulation has a Procedure which effectively 


eS) 


(5) 


(6) 


(7) 


(8) 


picks out the pertinent data and converts them to either integer 
or real values based on the use. 


Pertinent data from this file which is stored and used by the 
simulation is: time period, aircraft type flying sorties, target 
type sorties are flown against, EKS per sortie, probability of no 
weather aborts (NABORT) for the particular sorties, attrition per 
sortie, and sorties flown. 


All data is used "as is”, with the exception of sorties flown, which 
are reported as real valued quantities by the GAMS model. For this 
simulation we are interested in integer values (since you can only 
fly a whole number of sorties in real life!), therefore, after the 
real number of sorties flown is uniformly distributed over the current 
period, another Procedure is used to round this either up or down, 
based on a U[0,1]} random number, to an integer value. The integer 
number of sorties is then the quantity used by the simulation. When a 
kill is made by a sortie, the same is done to the EKS value for 

that particular sortie since you can only kill an integer number 

of targets in real life! 


Output will be the objective function value after a large number 

of replications (see NUMBERREPS below in CONST declarations). Extra 
output statistics can also be obtained by removing comment brackets 
from those places noted in the Main Program part of the Simulation 
below. Output is sent to “sim2out.csv”, which can be viewed in 
Excel spreadsheet format. There are code options to allow output to 
go to the computer screen also. 


Data which should be the same as the GAMS model LP is: 


time period 

aircraft types 

target types 

EKS per sortie 

probability of no weather aborts 

attrition per sortie 

number of aircraft starting for each type (integer) 
max loss allowed for each aircraft type (integer) 
sortie rate for each aircraft type 

TVDWGT 

GOALWGT 

number of periods 

number of planning cycles (days) in each period 
kill goals for each target class 

number of targets starting for each type (integer) 
penalties for not achieving kill goals for each target class 
target class-target correspondence 

repair proportion/probability for each target type 
probability of correct BDA for each target type 


Probabilities used in the simulation are (GAMS model data or 
variable name correspondence, if any, is shown in parentheses next 
to each): 


aircraft attrition (ATTR) 

prob. of no weather abort (NABORT) 

target BDA prob-, i.e. probs @fiscorrect BDA for a target {BDAPROB, 
B (as used in target regeneration and BDA equations) ) 

prob. of incorrect BDA for a target (NB (= 1 - B as used in target 
regeneration and BDA equations) ) 

prob. the target is repairable after a strike (REPROP, Pr (as used 
in target regeneration and BDA equations) ) 

prob. a target is not repairable (NPr (= 1 - Pr as used in target 
regeneration and BDA equations) ) 

prob. a target regenerates in the next planning cycle (Pc (as used 
in target regeneration and BDA equations) ) 

prob. a target does not regenerate in the next planning cycle (NPc 
(= 1 - Pe as used in target regeneration and BDA equations) ) 

conversion of real no. of sorties flown to integer (x) 

conversion of real valued sortie rates to integer (SRTRTPER) 

conversion of real no. of targets killed from associated EKS 
to integer (EKS) 

choice from which category restrikes will come 


Output generated by this simulation to be compared with LP: 


mean objective function value for weighted sum of target value 
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destroyed (TVD) over a large number of replications 
Additional output generated by simulation: 


standard deviation for mean objective function value 
number of replications done 


(9) Pata anput files are “simlin.dat", “tgtval22.dat", 
"tgtdat22.dat", and “tsvtst.dat". Output file is 
VSimeout. csv” . 


(10) Note that the MAXLOSS values in the GAMS model input file 
"standl3.dat” must also be rounded to integer values so the GAMS 
model and simulation both use the same data. This is also true of 
the number of aircraft and targets of each type in their respective 
data input files. 


(11) There is no data input error trapping so data in input files 
must be entered correctly and also be meaningful for proper 
output to be generated. Basically, a user knowledgeable of the 
GAMS model and simulation is assumed here! 


(12) *** IMPORTANT! *** Set the STACK and HEAP sizes of the compiler 

on the machine this is run on to 15,000 bytes (minimum) each. 
This is needed so the data segment created by this program is 
accepted by the compiler, otherwise there will be a stack overflow 
runtime error. Note: Don't go overboard either! Setting the 
STACK and HEAP sizes too large will prevent the compiler from 
compiling if the machine this is run on does not have enough 
memory to support it. 

} 


Uses WinCrt; 


Const 
NUMBERREPS = 1000; {set number of replications here} 
SEEDFORRANDNUMS = 999; {seed for random numbers so they are the same each time if needed} 
MAXNUMPERIODS = 7; {max number of periods} 
MAXNUMACETTYPES = 10; {max number of aircraft types expected to be encountered) 
MAXNUMIGTIYPES = 87; {max number of target types} 
MAXNUMTGTCLASSES = 10; {max number of target classes} 
MAXNUMDISTBANDS = 7; {max number of distance bands} 
REPOUT1 = 1; {replication output instance} 
REPOUT2Z = 1057; {replication output instance} 
REPOUT3 = 1092; {replication output instance} 
Type 
PeriodIndexRange = 1..MAXNUMPERIODS; 
AcftTypeIndexRange = 1..MAXNUMACFTTYPES; 


TgtTypeIndexRange = 1..MAXNUMTGTTYPES; 

TgtClassIndexRange = 1..MAXNUMTGTCLASSES; 

AcftTypeArray = Array[{AcftTypeIndexRange] Of Integer; 

SortieRateArray = Array(AcftTypeIndexRange] Of Real; 

TgtValueArray = Array([TgtTypeIndexRange, PeriodIndexRange] Of Real; 
TgtKillArray = Array{TgtTypeIndexRange, PeriodIndexRange] Of Integer; 
TgtRealTypeArray = Array{TgtTypeIndexRange] Of Real; 

TgtIntTypeArray = Array[TgtTypeIndexRange] Of Integer; 

KillGoalArray = Array[TgtClassIndexRange, PeriodIndexRange] Of Real; 
TgtClassTgtArray = Array|[TgtClassIndexRange, TgtTypeIndexRange] Of Integer; 
TgtClassArray = Array[TgtClassIndexRange] Of Integer; 

StringlType = String{10]; 


Function UniformProb: Real; 

{ 
A uniform [0,1] random number generator available for any procedure or 
function which requires a U{0,1] probability. 


Pre: None. 
Poses U0,4 | probability. 
} 
Begin {Function UniformProb} 
UniformProb := Random; 
End; {Function UniformProb)} 


Function Binomial (Num: Integer; 
Prob: Real): Integer; 
{ 
Determines the number of possibilities from a certain number of samples, Num, which 
meet the condition U{0,1] <= Prob, where Prob is a particular probability from 
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any particular distribution desired which was calculated previously and passed to 
this Function. 


Pre: Num = total number of samples (must be > 0); Prob = probability for a U{0,1] 
to be compared against. 
Post: “Binomial = number ove of the total for which UlG,1)) <— "brob is true. 
} 
Var 
I, Count: Integer; 


Begin {Function Binomial} 
Count 2.=.0; 
For I := 1 To Num Do 
Begin 
If (UniformProb <= Prob) Then 
Begin 
Count := Count + i; 
Encaea (1th 
End; {Forj 
Binomial := Count; 
End; {Function Binomial) 


Function GetInteger (Num: Real): Integer; 

{ 
Converts a Real number to an Integer number by rounding either up or down based 
on a U[0,1] random number. 


Pre: Num = Real number 

Post: GetInteger = Integer number 
} 
Var 

Result: Integer; 


Begin {Function GetInteger} 
If (UniformProb <= Frac(Num)) Then 


Begin 

Result := Trunc(Num) + 1; 
End 
Else 
Begin 

Result := Trunc (Num); 
Ena- O{Tr} 
GetInteger := Result; 


End; {Function GetInteger} 


Function Raise (Base: Real; 
Exponent: Integer): Real; 
( 
Raises the Base to the Exponent power. 


Pre: Exponent > 0 

Post: Raise = Base to the Exponent power 
} 
Var 

Count: Integer; 

Product: Real; 


Begin {Function Raise} 


Product  := 1; 
For Count := 1 To Exponent Do 
Begin 

Product s= Product =~ Base, 
Ends {For} 


Raise := Product; 
End; {Function Raise} 


Procedure GetRealNumber (St: StringType; 
Var x: Real); 
{ 
Converts a string to it’s real valued number. Only handles positive numbers, and 
if the number will be < 1, there must be a leading zero before the decimal point, 
e.g. St = *0.0394' vice St-=" 10392 — 


Pre: St = a string of type StringType. 

Post: x = the real valued quantity imbedded in St. 
} 
Var 

I: Integer; 
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Numl, Num2: Real; 
OnPeriod: Boolean; 
Stig. St2: “String lype-s 


Begin {Procedure GetRealNumber} 
Numl := 0.0; 


OnPeriod := True; 
For 1 := 1 To Lengen (semis 
Begin 
Ef ((St( hil <>)" je Ane (eneeri6d)) Then 
Begin 
Sti <= Stl + Stil}; 
End 
Else 
Begin 
If OnPeriod Then 
Begin 
OnPeriod := False; 
End 
Else 
Begin 
St2ac= St2 + Stliic 
Enea? it} 
End; {if} 
End; {For} 
For I = 1 To Lengtni(Sti) De 
Begin 
Numl := Numl + (Ord(St1[I]) - 48) * Raise (10, (Length(St1) - I)); 
Ena: {For} 
Li (Length (St2Z) 270) Then 


Begin 
FOr d i= 1) To Length (St2): pe 
Begin 
Num2 := NumZ2 + (Ord(St2[I]) - 48) * Raise (10, (Length(St2) - I)); 
End; {For} 
Num2 := Num2 / (Raise (10, Length(St2))); 
End; {If} 


x := Numl + Num2; 
End; {Procedure GetRealNumber} 


Function GetTargetClass (Tgt: Integer; 
TgtClassTgt: TgtClassTgtArray; 
TgtsInClass: TgtClassArray; 
NumTgtClasses: Integer): Integer; 
{ 
For a given target type, determines which target class it belongs to. 


Pre: Target type in question, target Class data arrays, and number of target classes. 
Post: GetTargetClass = Target class the target belongs to. 

} 

Var 
Class, Target, Temp: Integer; 


Begin {Function GetTargetClass} 
For Class := 1 To NumTgtClasses Do 


Begin 
For Target := 1 To TgtsInClass[Class] Do 
Begin 
If (TgtClassTgt [Class, Target] = Tgt) Then 
Begin 
Temp := Class; 
Target := TgtsInClass[Class]; 
Class := NumTgtClasses; 
Ene? 9 {i2) 
Ends thor! 
End; {for} 


GetTargetClass := Temp; 
End; {Function GetTargetClass} 


Procedure RunSimulation (NumDays, NumAcft, MaxLoss: Integer; 
SortieRate: Real; 
Var AcftLost: Integer; 
TOLEITGts: Integer; 
Tgwval, Goals. Real: 
Eks, Nabort, Attr, x: Real; 
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Var TotSortiesFlown: Integer; 

Pr, NPr, Pc, NPc, B, NB: Real> 

Var LiveN, DeadN, RegenN: Integer; 

Var LiveR, DeadR, RegenR, deltaTgtsKilled: Integer; 
Var TempTvd: Real); 


For the given mission data, runs the simulation and determines the Target Value 

Destroyed (TVD). This Procedure is run for one aircraft type, flying a certain profile, 
against a particular target type, with sorties distributed uniformly over one period. 

The simulation loops through the days in the period and the number of aircraft in 

the aircraft type until all sorties are flown, OR all the targets of the target type 

are killed, OR the max number of the aircraft type are lost, OR the kill-goal for the 
period has been achieved. It is important to note that this Procedure is run once for 
each line of data in “"tsvtst.dat"™. It essentially re-flies the sorties the GAMS model 
flew and determines the outcome randomly for later comparison with the GAMS model results. 


Pre: See the parameters passed to the Procedure above. 

Post: For a particular engagement flown, updates aircraft of the aircraft type lost, 
targets of the target type killed, future restrikes and repairable targets, 
future regeneration of targets, and total TVD. 


Variable definitions: 
*** For parameters passed to the Procedure, see Main Program variable definitions as 
the same names for them were used. 


AcftKilled - stores a Boolean value for whether or not an aircraft is attrited. 

AcftWxAbort - stores a Boolean value for whether or not an aircraft experiences an 

in-flight weather abort. 

delta - used generically to determine an incremental change in some integer variable. 

deltaB - used to store the number of kills from the total amount made as a result of 

a regular strike based on the probability "B™ which will go to the 
"non-restrikeable” category (become either DeadN or RegenN). 

deltaBNPr - used to store the number of kills from deltaB which will become DeadN 

based on the probability "NPr". 

deltaBPr - used to store the number of kills from deltaB which will become RegenN 

based on the probability "Pr”. 

deltaNB ~ used to store the number of kills from the total amount made as a result of 

a regular strike based on the probability "NB" which will go to the 
"restrikeable” category (become either DeadR or RegenR). 

deltaNBNPr - used to store the number of kills from deltaNB which will become DeadR 

based on the probability "NPr”. 

deltaNBPr - used to store the number of kills from deltaNB which will become RegenR 

based on the probability "Pr". 

deltaPd - used to store the number of periods ahead of the current one that a target 

will be regenerated in. 

I - counter variable for loops. 

InRegularStrikePhase - boolean variable which indicates whether the regular strike phase 
has been entered or not in the current day so as to prevent the 
restrike phase from occurring more than once per day. 

K - counter variable for loops. 

MaxSortiesToday - the integer max number of sorties which may be flown today based on 
sorties per day as derived from the sorties flown for the period 
read in from "tsvtst.dat”. 

NumTgtsKilled - integer number of targets killed by a successful sortie based on EKS. 

PropKilled - cumulative proportion of targets of the target type killed. 

RTypeTotal - total number of targets in all restrike categories which are currently 

subject to restrike. 

SortiesFlownToday - counter to keep track of the sorties flown on the particular day 
for comparison to see if the max sorties for the day have been 
flown. 

SortiesPerAcftPerDay - sortie rate for each aircraft of the aircraft type. 

SortiesPerDay - sorties per day, uniformly distributed over the period. 

SortiesToFly - the sorties which will actually be flown on a particular day. 

Start - the starting point for the For loop over the number of aircraft of the aircraft 

type. 

TempPropKkilled - temporary proportion of the total number of targets killed; calculated 
in advance to compare to the kill-goal before kills are actually applied 
to the LiveN type targets. 

WhichRType - random variable to aid in deciding from which restrike category the kills 

held in the variable NumTgtsKilled will be applied to. 


Notes for below: 


— ee ee ee ee ee ee oe oe = 


(1) This uniformly distributes the number of sorties to be flown over the period. 
The integer number of sorties actually flown on any day is found using 
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(2) 


(3) 


(4) 


(5) 
(6) 


(7) 


(8) 


(9) 


(10) 


Gin) 


(12) 


Gis) 


(14) 


Var 


SortiesPerDay in the Function GetInteger. SortiesPerAcftPerDay is the sortie 

rate for each aircraft of the particular aircraft type. 

While there are sorties left to fly in this day, and the max number of aircraft 
have not been lost, and the total amount of targets in this type have not been 
killed, and the kill-goal for the period has not been met, sorties may still be 
flown. 

If an aircraft is attrited, it is lost, and therefore any sorties it had left to 
fly are also lost. 

If an aircraft is not attrited and does not experience an in-flight weather abort, 
it is expected to make kills based on EKS. However, a sortie cannot kill more 
targets than the total amount of the target type present (common sense!), 
therefore this is also accounted for and the number of kills from the sortie 
adjusted if necessary. Also, a sortie is restricted by the kill-goal for this 
target type for the particular period, kill goals being cumulative across the 
periods. The sorties may kill up to the goal, under the goal, but not over the 
goal. 

The target value credited is for every target of this target type which is dead or 
in repair over all periods up through the current one, up to the current kill-goal. 
While there are mis-classified targets scheduled for restrike due to bad BDA in 
the previous planning cycle, and there are sorties left to fly in this day, and 
the max number of aircraft have not been lost, and the max number of sorties for 
the day have not been flown yet, these restrikes must be done first before other 
targets are engaged. Note, an aircraft doing restrikes is still subject to 
aecritlon, 

The proportion killed are the dead targets plus targets in repair divided by the 
total number of targets of the target type starting. It is calculated this way 
because targets in repair where initially killed to get them into that category, 
and are recognized as dead until they reappear. This is the quantity which is 
compared to the kill-goal for the target type. Note: There is no chance for 
division by zero in the calculation of the proportion since the denominator 
remains unchanged throughout the entire program run. The quantity in the 
denominator will always contain the total number of targets of the target type 
which started the program run, the total amount killed being kept track of by 
other variables and compared to the original number present to determine the 
proportion killed. This is convenient calculation wise since kill-goals are 
cumulative over time. Also, this simulation routine is only run for valid 
sortie-target engagement combinations as determined by the GAMS model, so the 
quantity in the denominator will always be a quantity greater than zero. 

Any targets under repair but restrikeable will either become dead forever or under 
repair and NON-restrikeable. Any targets which are live and restrikeable are 
targets which have just came out of repair but are immediately restruck, and then 
become either dead forever or under repair and NON-restrikeable. 

This If..Then represents the case in which all restrikeable targets have been 
restruck, but the last restrike sortie flown resulted in overkill, i.e., the 
number of targets killed based on the sortie's EKS was greater than the number 

of targets left to restrike. Therefore, this overkill is applied to live targets 
aS a regular strike, where it is assumed that live targets existed in the 

vicinity of the restrikes when they occured, however, the overkill is applied 
without the risk of aircraft attrition or weather abort since these were already 
checked for when the sortie occured. 

Note that an aircraft which suffers an in-flight weather abort is still subject to 
attrition, thus explains the position of this conditional check in the overall 
If..Then structure - 

Each surviving aircraft of the aircraft type gets a chance to fly the sorties per 
day, in accordance with their sortie rate, until all the days are done or sorties 
have been flown, or the kill goal is reached. The total sorties which may be flown 
by all aircraft for each day, however, is capped at a maximum derived from the 
sorties flown from "tsvtst.dat”. When the limit has been reached, we skip to 

the next day. 

Any dead and restrikeable targets, i.e., mis-BDA'd, will, with probability 1.0, 
become dead forever when restruck because their "true identity” becomes known 

upon restrike. 

The current sortie on a restrike mission was not attrited and did not experience a 
weather abort, so the category of targets it will restrike will be decided randomly 
with the category having the most number of restrikeable targets having the higher 
probability of being picked. 

A temporary proportion of the total targets killed is calculated in advance before 
the current value of NumTgtsKilled is applied to the LiveN type targets so it can 
be predicted whether or not applying all the kills will cause the kill-goal to be 
exceeded. If the kill-goal would be exceeded, NumTgtskKilled is successively 
decremented by 1 until either the predicted value of PropkKilled does not exceed the 
kill-goal, or NumTgtsKilled equals 0. 


SortiesToFly, NumTgtsKilled, deltaB, deltaNB, deltaBPr, deltaBNPr: Integer; 
I, K, deltaPd, delta, deltaNBPr, deltaNBNPr, RTypeTotal: Integer; 
SortiesFlownToday, MaxSortiesToday, Start: Integer; 

PropKilled, SortiesPerDay, SortiesPerAcftPerDay, WhichRType: Real; 
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TempPropKilled: Real; 
AcftKilled, AcftWxAbort, InRegularStrikePhase: Boolean; 


Begin {Procedure RunSimulation} 


SortiesPerDay := x / NumDays; {** Note 1 <**} 
SortiesPerAcftPerDay := SortieRate; {e* Note 1° >=) 
AcftKilled := False; 


AcftWxAbort := False; 
Start. += ACEC Lost + 1; 
For I := 1 To NumDays Do 
Begin 


*¥**4% Regeneration Phase ***** 


If (RegenN > 0) Then 


Begin 
delta := Binomial (RegenN, Pc); 
LiveN := LiveN + delta; 
RegenN := RegenN - delta; 
Endy (Le) 
If (RegenR > 0) Then 
Begin 
delta := Binomial (RegenR, Pc); 


LiveR := LiveR + delta; 
RegenR := RegenR - delta; 


End; {If} 
{ PropKilled := DeadN / TotTgts;} {** debug alternative to next line **} 
PropKilled := (DeadN + RegenN + DeadR + RegenR) / TotTgts; {** Note 7 **} 


MaxSortiesToday := GetInteger (SortiesPerDay); 
SortiesFlownToday := 0; 
InRegularStrikePhase := False; 
For K := Start To NumAcft Do {** Note 11 **} 
Begin 
SortiesToFly := GetInteger (SortiesPerAcftPerDay) ; 
{ 
#e"**% Rest rike Phases. ==." 
} 
NumTgtsKilled := 0; 
While ((SortiesToFly > 0) And (AcftLost < MaxLoss) And ((LiveR > 0) Or (DeadR > 0) Or 
(RegenR > 0)) And (SortiesFlownToday < MaxSortiesToday) And 
(Not InRegularStrikePhase)) Do {** Note 6 **} 
Begin 
SortiesFlownToday := SortiesFlownToday + 1; 
SortiesToFly := SortiesToFly - 1; 
TotSortiesFlown := TotSortiesFlown + 1; {** Data purposes only **} 
AcftKilled := (UniformProb <= Attr); 
If AcftKilled Then 
Begin 
ACEELOSE = AciEbose + 2); 
Sortiesitokly *= 02 {** Note 3 **} 
End 
Else 
Begin 
ActtWxAbort == (Uniformerob > Nabort): {** Note 10 **} 
If (Not AcftWxAbort) Then 
Begin 
NumTgtsKilled := GetInteger (Eks); {** Note 4 **} 
While ((NumTgtsKilled > 0) And ((LiveR > 0) Or (DeadR > 0) Or (RegenR > 0))) Do 
Begin  {** Note 13° *=} 
RTypeTotal := LiveR + DeadR + RegenR; 
WhichRType := RTypeTotal * Random; 
If ((WhichRType <= LiveR) And (LiveR > 0)) Then 


Begin 
If (LiveR <= NumTgtsKilled) Then {** Note 8 **} 
Begin 
NumTgtsKilled := NumTgtsKilled - LiveR; 
delta := Binomial (LiveR, Pr); 


LiveR := LiveR - delta; 
RegenN := RegenN + delta; 
DeadN := DeadN + LiveR; 
LiveR := 0; 
End 
Else 
Begin 
LiveR := LiveR - NumTgtsKilled; 
delta := Binomial (NumTgtsKilled, Pr); 
NumTgtsKilled := NumTgtsKilled - delta; 
RegenN := RegenN + delta; 


42 


DeadN := DeadN + NumTgtsKilled; 
NumTgtsKilled := 0; 
End; {If} 
End 
Else If ((WhichRType <= DeadR) And (DeadR > 0)) Then 
Begin 
If (DeadR <= NumTgtsKilled) Then {** Note 12 **} 
Begin 
NumTgtsKilled := NumTgtsKilled - DeadR; 
DeadN := DeadN + DeadR; 
DeadR := 0; 
End 
Else 
Begin 
DeadR := DeadR - NumTgtsKilled; 
DeadN := DeadN + NumTgtsKilled; 
NumTgtsKilled := 0; 
End; {if} 
End 
Else 
Begin 
If (RegenR > 0) Then {** Note 8 **} 
Begin 
If (RegenR <= NumTgtsKilled) Then 
Begin 
NumTgtsKilled := NumTgtsKilled - Regenk; 
delta := Binomial (RegenR, Pr); 
RegenR := RegenR - delta; 
RegenN := RegenN + delta; 
DeadN := DeadN + RegenR; 
RegenR := 0; 
End 
Else 
Begin 
RegenR := RegenR - NumTgtsKilled; 
delta := Binomial (NumTgtsKilled, Pr); 
NumTgtsKilled := NumTgtsKilled - delta; 
RegenN := RegenN + delta; 
DeadN := DeadN + NumTgtsKilled; 
NumTgtsKilled := 0; 
Ena;  {1£} 
End; tif) 
End; {If} 
End; {While} 
End; {If Not AcftWxAbort} 
End; {If AcftKilled} 
End; {Main While loop for Restrike Phase} 


= Regular Strike and Redistribution of Kills Phase ***** 


eke kk ke kee 


The If..Then below allows any left over "kills" in the variable NumTgtsKilled which 
were not needed to complete all the restrikes from the restrike phase above to be 
applied to LiveN targets, if any. Remove the single comment brackets in column 1 
ONLY if you want to use this code. ** Note ** This is not consistent with how Time 
Strike allocates sorties across time accounting for restrikes, but can be used for 


exploratory purposes by the user. 
i de ee te ae 


If ((LiveR = 0) And (DeadR = 0) And (RegenR = 0) And (NumTgtsKilled > 0) And 
(LiveN > 0)) Then {** Note 9 **} 

Begin 

TempPropKilled := (DeadN + RegenN + DeadR + RegenR + NumTgtsKilled) / TotTgts; 

While ((TempPropKilled > Goal) And (NumTgtsKilled > 0)) Do {** Note 14 **} 


Begin 
NumTgtsKilled := NumTgtsKilled - 1; 
TempPropKilled := (DeadN + RegenN + DeadR + RegenR + NumTgtsKilled) / TotTgts; 


End; {While} 
If (NumTgtsKilled > 0) Then 
Begin 
If (LiveN <= NumTgtsKilled) Then 
Begin 
deltaTgtsKilled := deltaTgtsKilled + LiveN; 
deltaB := Binomial (LiveN, B); 
deltaNB := LiveN - deltaB; 
LiveN := 0; 
End 
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Else 

Begin 
deltaTgtsKilled := deltaTgtsKilled + NumTgtsKilled; 
deltaB := Binomial (NumTgtsKilled, B); 
deltaNB := NumTgtsKilled - deltaB; 


LiveN := LiveN ~— NumTgtsKilled; 
ENG A {li} 
If (deltaB > 0) Then 
Begin 


deltaBPr := Binomial (deltaB, Pr); 
deltaBNPr := deltaB - deltaBPr; 
RegenN := RegenN + deltaBPr; 
DeadN := DeadN + deltaBNPr; 

ap he a fee ae | 
If (deltaNB > 0) Then 

Begin 
deltaNBPr := Binomial (deltaNB, Pr)? 
deltaNBNPr := deltaNB - deltaNBPr; 
RegenR := RegenR + deltaNBPr; 
DeadR := DeadR + deltaNBNPr; 


End; {If} 

End; {If} 
End; {If} 
PropKilled := DeadN / TotTgts; {** debug alternative to next line **} 
PropKilled := (DeadN + RegenN + DeadR + RegenR) / TotTgts; {** Note 7 **} 


While ((SortiesToFly > 0) And (AcftLost < MaxLoss) And (LiveN > 0) And 
(DeadN < TotTgts) And (PropKilled < Goal) And 
(SortiesFlownToday < MaxSortiesToday)) Do {** Note 2 **} 
Begin 
InRegularStrikePhase := True; 
SortiesFlownToday := SortiesFlownToday + 1; 
SortiesToFly := SortiesToFly - 1; 
TotSortiesFlown := TotSortiesFlown + 1; {** Data purposes only **} 
AcftKilled := (UniformProb <= Attr); 
If AcftKilled Then 
Begin 
AcftLost := AcftLost + 1; 
Sortiesiabive:=— 07 ".(** Note 3 <*} 
End 
Else 
Begin 
AcftWxAbort := (UniformProb > Nabort); {** Note 10 **} 
If (Not AcftWxAbort) Then 
Begin 
NumTgtsKilled := GetInteger (Eks); {** Note 4 **} 
TempPropKilled := (DeadN + RegenN + DeadR + RegenR + NumTgtsKilled) / TctTgts; 
While ((TempPropKilled > Goal) And (NumTgtsKilled > 0)) Do {** Note 14 <*¥*} 
Begin 
NumTgtsKilled := NumTgtsKilled - 1; 
TempPropKilled := (DeadN + RegenN + DeadR + RegenR + NumTgtsKilled) / TctTgts; 
End; {While} 
If (NumTgtsKilled > 0) Then 
Begin 
If (LiveN <= NumTgtsKilled) Then 
Begin 
deltaTgtsKilled := deltaTgtsKilled + LiveN; 
deltaB := Binomial (LiveN, B); 
deltaNB := LiveN ~ deltaB; 
LiveN := 0; 
End 
Else 
Begin 
deltaTgtsKilled := deltaTgtsKilled + NumTgtsKilled; 
deltaB := Binomial (NumTgtskKilled, B); 
deltaNB := NumTgtsKilled - deltaB; 
LiveN := LiveN - NumTgtskilled; 
End; {If} 
If (deltaB > 0) Then 
Begin 
deltaBPr := Binomial (deltaB, Pr); 
deltaBNPr := deltaB - deltaBPr; 
RegenN ;:= RegenN + deltaBPr; 
DeadN := DeadN + deltaBNPr; 
End; NG ae 
If (deltaNB > 0) Then 
Begin 
deltaNBPr := Binomial (deltaNB, Pr); 
deltaNBNPr := deltaNB - deltaNBPr; 
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RegenR := RegenR + deltaNBPr; 
DeadR := DeadR + deltaNBNPr; 
End> {22} 
End; {If} 
{ Prep Rrllcl : we -actiers Tocigts; } 6) debug alternative to next line **} 
PropKilled := (DeadN + RegenN + DeadR + RegenR) / TotTgts; {** Note 7 **} 
End; {If Not AcftWxAbort } 
End; {If AcftKilled} 
End; {While loop for Regular Strike and Redistribution of Kills Phase} 
If (SortiesFlownToday >= MaxSortiesToday) Then {** Note 11 **} 


Begin 
K := NumAcft; 
End;  “UGell 


End; {For loop for aircraft} 
Start := AcftLost + 1; 
End; {For loop for days} 
TempTvd := TgtVal * (DeadN + RegenN + DeadR + RegenR); {** Note 5 **} 
End; {Procedure RunSimulation} 


Procedure GetPdiffValues (NumPeriods, NumTgtTypes, NumTgtClasses: Integer; 
TgtsDeadOrInRepair: TgtKillArray; 
TotTgts: TgtIntTypeArray; 
TgtClassTgt: TgtClassTgtArray; 
TgtsiInClass: TgtClassArray; 
Goal: KillGoalArray; 
Var Pdiff: TgtValueArray) ; 


Calculates the pdiff values (proportion of kills below the goal for each target type 
in each period) to be used in the objective function calculation. Note that there 

are no targets present of some target types, so sorties are not flown against them. 
Therefore, division by zero must be accounted for below. Also, if there are targets 
of a target type present, but no kills were made, pdiff is merely set to the kill-goal 
for the target class, i.e., max penalty possible is charged for the case-in-point. 


Pre: Number of periods, target types, and target classes present. Cumulative number 
of targets of each type dead or in repair each period by period, total targets of 
each type which were present/alive at the start of the program run. Target 
Class-Target correspondence data along with the number of target types in each 
Class. Kill goals for each target class in each period. 

Post: Pdiff array = proportion of kills below the goal for each target type in 
each period 

} 

Var 
Ea, (qt, Class, I, TotTgqtskilled: Integer; 
PropKilled: Real; 


Begin {Procedure GetPdiffValues} 
For Pd := 1 To NumPeriods Do 
Begin 
For Tgt := 1 To NumTgtTypes Do 
Begin 
Class := GetTargetClass (Tgt, TgtClassTgt, TgtsInClass, NumTgtClasses) ; 


Kee eee KEE 


Total targets killed (actually dead or in repair) are calculated with a For loop here 
because the cumulatives used in the proportion calculation below must be for only the 
target type up through the current period of the outer loop. 


whe te te te te te de te te ke 


TotTgtsKilled := 0; 
For I := 1 To Fado 
Begin 
TotTgtskilled := TotTgtsKilled + TgtsDeadOrInRepair[Tgt,1I]; 
End; {For} 
TEw(TOttgts | Tqt}] <> 0)" Then 
Begin 
PropKilled := TotTgtsKilled / TotTgts{Tgt}; 
End; {If} 
If ((TotTgts[Tgt] <> 0) And (PropKilled <= Goal[Class,Pd])) Then 
Begin 
Pdiff[Tgt,Pd}] := Goal[Class,Pd] - PropKilled; 
End 
Else 
Begin 
PALEDI Tete bape =7 0.0; 
End; {1£} 
End? (for) 
End> {For} 


45 


End; {Procedure GetPdiffValues} 


Function CalculateObjFenValue (NumPeriods, NumTgtTypes, NumTgtClasses: Integer; 


} 


TgtClassTgt: TgtClassTgtArray; 
TgtsinClass=: TIqgtClassArray; 
Iva. Rea: 

Ppen: KillGoalArray; 

Pdiff: TgtValueArray; 

TvdWgt, GoalWgt: Real): Real; 


Calculates objective function value for maximizing the weighted sum of TVD. The 
Procedure does not actually maximize the value, it calculates the objective function 
value based on TVD gained for a replication of the simulation for which sorties were 
already assigned by the GAMS model, but the results of the sorties were decided 
randomly by this simulation. After the random results of the sorties, kill-goal 
achievement was determined, and then the resultant values for cumulative TVD collected 
and the pdiff values are passed to this Procedure, then the calculation proceeds as 

in the objective function contained in the GAMS model. 


Pre: Number of periods, target types, and target classes present. Target 
Class-Target correspondence data along with the number of target types in 
each class. The target value destroyed which has been credited for the current 
replication of the simulation. The objective function penalty for not meeting 
the kill-goal for each target class in each period. The objective function 
weights for TVD and goal achievement. 

Post: CalculateObjFcnValue = Weighted sum of TVD 


Var 


Pd, Tqt, Class: integer; 
Penalty: Real; 


Begin {Function CalculateObjFcnValue } 


Penalty := 0.0; 
For Pd := 1 To NumPeriods Do 


Begin 
For Tgt := 1 To NumTgtTypes Do 
Begin 
Class := GetTargetClass (Tgt, TgtClassTgt, TgtsinClass, NumTgtClasses) ; 
Penalty := Penalty + (Ppen[Class,Pd] * Pdiff[Tgt, Pd]); 
End; {For} 
Enas {FOr} 


CalculateObjFenValue := (TvdWgt * Tvd) + (GoalWgt * Penalty); 


End; {Function CalculateObjFenValue} 


{ 


a ee ee eee ee ee ee eee ee ee eee ee ee ee ee 
Keke eke Ke Kae Kee KEK KK Main Program St ee 


se ie ete te ee ee ee ete ee te ie ete ee ee te ee ee oe oe te ie ie eee te ee te ee a a ee a a a ee kk kk ee 


The Main Program is used to assign input and output files, open and close 

input and output files, input all the necessary data from the input files, 

and output the data to the output file. The Main Program is the only part 

of the simulation which reads and outputs data, the other Procedures and 
Functions are the ones which manipulate the data with regards to actually 
performing the simulation. This prevents having to instantiate too many 

array types when passing data from the Main Program to a Procedure or Function, 
which in turn would use up much too much memory since the array types defined 
are quite large! 


The only actual calculations done by the Main Program are for intermediate 
values which must be output for debug purposes or statistical data for the user. 
Comments are imbedded within the Main Program code below which indicates which 
lines should be kept or commented out based on user preference for the output 
generated by the debug lines of code, or to add or subtract output as the user 
sees fit. 


Main Variable definitions: 

Acft - counter variable for aircraft types. 

AcftLost - array of the cumulative number of aircraft lost for each aircraft type over 

the whole simulation run. 

AcftType - array of aircraft types actually flying sorties. 

Attr - losses per sortie (probability of attrition per sortie in the range [0,1]}). 

B - probability of correct BDA for a target (B = BdaProb[Tgt]). 

BdaProb - array of the BDA probabilities for each target. 

BeforeTgtsDeadOrInRepair - the number of targets of the target type dead or in repair 
just before the simulation routine is run for the next 
engagement against the target type. 

Ch ~ a Char type variable used for reading data from "tsvtst.dat™ character by 
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character to get the real valued quantities and disregard the commas. Used 
in conjunction with the variable 'St' as defined below. 

Class ~ counter variable for target classes. 

DataValRead - counter variable which keeps track of how many data values have been 
read in “"tsvtst.dat™ to determine which simulation variable to store 
the quantity in. 

DeadN - array of the current number of dead targets which ARE NOT restrikeable for 

each target type (dead forever). 

DeadR - array of the current number of dead targets which ARE restrikeable for each 
target type; the only possibility for these are to become dead forever (see 
DeadN above) when restruck. 

deltaTgtsKilled - difference between total targets of the target type killed after the 

Simulation routine is run and BeforeTgtsKilled, i.e., the number of 
targets of the target type killed during the last particular run of 
the simulation routine. 

DistBandNum - counter variable for distance band numbers. 

Eks - expected kills per sortie for an aircraft type in a particular period. 

Goal - array of the proportion of targets in each target class to be killed to 

achieve the goals in each period. 

GoalWgt ~ objective function weight for goal achievement. 

I ~- counter variable for For loops. 

LiveN - array of the current number of live targets which ARE NOT restrikeable for 
each target type. 

LiveR - array of the current number of live targets which ARE restrikeable for each 
target type; these represent the number of targets which have just come out 
of repair in the planning cycle but may be restruck and returned to repair 
{see RegenN below), or become dead forever (see DeadN above). 

MaxLoss - array of the max loss allowed of each aircraft type. 

Nabort - probability there is no weather abort in flight for a particular aircraft 

type flying sorties against a particular target type. 

NB - probability of incorrect BDA for a target (NB = 1 - B). 

NPc = probability a target does not regenerate in the next planning cycle (NPc = 1 = Pc). 

NPr - probability the target is not repairable after a strike (NPr = 1 - Pr). 

NumAcft - array of the number of aircraft for each aircraft type starting. 

NumAcftTypes - number of aircraft types which will fly sorties. 

Number - temporary storage location for a real valued number. 

NumDays - number of days (planning cycles) per period. 

NumPeriods - number of periods the simulation is run over. 

NumTgtClasses - number of target classes. 

NumTgtsInBand - temporary storage location for the read in number of targets in a 

particular distance band. 

NumTgtTypes - number of target types encountered in "tgtval22.dat”. 

Pc ~ probability a target regenerates in the next planning cycle. 

Pd - counter variable for periods. 

Pdiff - array of proportion of kills below the class goal for a particular target in 
a particular period. 

Ppen ~ array of objective function penalties for not meeting time-scripted goals 

for a target class by the end of a particular period (as contained in the 
Goal array). 

Pr -~ probability the target is repairable after a strike. 

RegenN - array of the current number of repairable targets which ARE NOT restrikeable 
EOr €d4en tdrqct Eype-. 

RegenR - array of the current number of repairable targets which ARE restrikeable for 
each target type; these may regenerate and become LiveR or remain RegenR 
during the regeneration phase, and then any RegenR may become RegenN or 
DeadN during the restrike phase. 

RepProp - array of the percent of killed targets that regenerate for each target; 

this is actually treated as a probability of repair in the Simulation. 

RepTime - array of the repair times for each target (repair times are in days). 

SimInFile(1-4) ~ files to get input data from. 

SimOutFile - file to send output data to. 

SortieRate - array of sortie rates (sorties per aircraft per day) for each aircraft 

type. 

St - string type variable used for storing data read from “tsvtst.dat”™ so the real 
valued quantities can be picked out of the lines of data since there are 
imbedded commas as a result of the GAMS model output. 

StdDev - the standard deviation of the TVD obj fcn values found over the number of 

replications performed. 

Sumv - sum of objective function values calculated for each replication of simulation. 

SumX1 - holds the sum of the x(i)*2 terms for the standard deviation calculation. 

SumX2 - holds the (sum of x(i))%2 term for the standard deviation calculation. 

Templ - temporary storage location for a Real value when reading in data. 

Temp2 - temporary storage location for a Real value when reading in data. 

TempSumTgts - temporary storage location for summing number of targets as the number 
in particular distance bands is read in. 

TempTvd - temporary storage location for TVD value returned by simulation; to be added 

later to the total. 

Tgt - temporary storage for a target type number. 
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TgtClassTgt - array of target class-target correspondence. 

TgtElts - temporary storage location for the data field for target elements in input 

file "tgtdat22.dat"; not used for anything, just provides a way of skipping 
unwanted data fields to get to wanted ones. 

TgtsDeadOrInRepair - array of cumulative number of targets dead or in repair for each 
target type BY PERIOD (not to be confused with the cumulative so far) 
over the whole simulation run; because of the nature of this variable, 
it may be possible that it has a negative quantity stored at the end 
of some periods (except the lst period), however, the sum of these 
quantities over all periods, or just more than one period, will always 
be a positive value (or zero). 

TgtsInClass - array of the number of targets in each class. 

TgtVal - array of target values for all targets over all periods. 

TotSortiesFlown - total number of sorties flown over all aircraft and all days for the 

last simulation run. 

TotTgts - array of the total number of each type of target. 

Tvd - sum of TVD values returned by simulation for each aircraft type in each period. 

TvdWgt - objective function weight for TVD. 

v - objective function value for weighted sum of TVD. 

x - number of sorties flown for a particular aircraft type against a particular target 

type. 


eee keer eee ke 


Lines of program code used for debug purposes only (which may also be useful to some 
users aS a normal part of the program) are annotated with *** debug *** in comment 
brackets. Any variables specifically declared and needed for their execution are 
defined below. These lines of code may be deleted or commented out without disturbing 
normal program execution, however, they must all either be deleted in their entirety or 
retained in their entirety because removal of only portions of *** debug *** code may 
disturb other portions retained if they relied on values obtained from the code that 
was removed. 


Debug Variable definitions: 

P - counter variable for For loops. 

PropKilled - cumulative proportion of targets of the target type killed. 
T - counter variable for For loops. 


we eee eee te 


Notes for below: 

(1) Have to read the aircraft types as seperate data and store them in an array, 
even though we know the number flying, because the types are not sequential, 

i.e., certain aircraft types may not be present in the GAMS model data for 
one reason or another. 

(2) Only desire certain data from "tsvtst.dat” (see comments at beginning of program), 
so any undesired data, i.e., not useful to the simulation run, is just dumped off 
into a temporary storage location, and then just discarded when another data item 
gets put there. Only certain data within the first 12 quantities in "tsvtst.dat” 
is required, so rather than wasting time in reading to the end of each line of 
data, the first 12 items are read, the useful data extracted, and then the rest 
of the line skipped. The GAMS model will always output data to tsvtst the same 
way, so this method of reading data will always apply. 

(3) This loop simply ensures that all the data meant to be output gets written to the 
output data file. This is required since sometimes long programs will terminate 
normally, but not all data will be written to the output file if it is sent to one 
(this problem does not exist if output only goes to the screen, but it’s nard to 
analyze data that way). The loop, therefore, slightly delays program termination 
so there is time for all data to get written to the output file. 

(4) The standard deviation will not be calculated or output unless at least 30 
replications are performed. This is so it will have at least some meaning when it 
is calculated. 

(5) This limits the number of times the obj fcn value is output for each replication to 
a maximum of 100 times, no matter how many replications are being done. This is 
done to prevent the output file from growing larger than typical spreadsheet 
software can handle. 


Var 
SimInFilel, SimInFile2, SimInFile3, SimInFile4, SimOutFile: Text; 
Che Char: 


NumPeriods, NumAcftTypes, NumTgtTypes, NumTgtClasses: Integer; 

Tgt, Pd, DistBandNum, Acft; "Class ,2., Tqtlits: Integer; 
NumTgtsInBand, TempSumTgts, NumDays, DataValRead: Integer; 
TotSortiesFlown, BeforeTgtsDeadOrInRepair, deltaTgtsKilled: Integer; 
Pe Ps -integer;  (*** “debug “=: 
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Attr, Tvd, TempTvd, v, Sumv, TvdWgt, Templ, Number: Real; 
GoalWgt, Eks, Nabort, Temp2, x, Pr, NPr, Pc, NPc, B, NB: Real; 
SumX1, SumX2, StdDev: Real; 

PropKilled: Real; {*** debug ***} 

TgtVal, Pdiff: TgtValueArray; 

TgtsDeadOrInRepair: TgtKiliArray; 

BdaProb, RepProp: TgtRealTypeArray; 

TotTgts, RepTime, LiveN, DeadN, RegenN, LiveR: TgtIntTypeArray; 
DeadR, RegenR: TgtIntTypeArray; 

AcftType, NumAcft, MaxLoss, AcftLost: AcftTypeArray; 
SortieRate: SortieRateArray; 

Goal, Ppen: KillGoalArray; 

TgtClassTgt: TgtClassTgtArray; 

TqgesinG@lass. (gee lassaArreay; 

St stent ype; 


Begin {Main Program} 
keh ke kkk ke 
Use only one of the following two seed statements for seeding the random number generator. 
Comment the other one out. 
KeKKK KKK KKK 
} 
RandSeed := SEEDFORRANDNUMS; {uses the Const declared seed so random nos. ARE repeated} 
{ Randomize; } {takes a seed off the system clock so random nos. ARE NOT repeated} 
Assign (SimInFilel, ‘sim2in.dat'); 
Assign (SimInFile2, ‘tgtval22.dat'); 
Assign (SimInFile3, ‘tgtdat22.dat'); 
Assign (SimInFile4, ‘tsvtst.dat'); 
Reset (SimInFilel); 
Reset (SimInFile2); 
Reset (SimInFile3); 
Reset (SimInFile4); 
Assign, (SimOutPile,  “SimZouc.csv"); 
ReWrite (SimOutFile); 


Keke kek kkk 


Read in target value data from "tgtval22.dat". 


ee ae a eo 


NumTgtTypes := 0; 

While (Not (SeekEof (SimInFile2))) Do 

Begin 
Read (SimInFile2, Tgt); 
NumTgtTypes := NumTgtTypes + 1; 
For Pd := 1 To MAXNUMPERIODS Do 


Begin 
Read (SimInFile2, TgtVal[Tgt,Pd]J); 
End; {For} 


ReadLn (SimInFile2); 
End; {While} 


Ke kkk ee ek 


Read in target data by distance band, total targets, bda probability, repair time, 
percent of killed targets that regenerate from "tgtdat22.dat". 


ek te ke he kee 


While (Not (SeekEof(SimInFile3))) Do 
Begin 
Read (SimInFile3, Tgt); 
TempSumTgts := 0; 
For DistBandNum := 1 To MAXNUMDISTBANDS Do 


Begin 
Read (SimInFile3, NumTgtsInBand) ; 
TempSumTgts := TempSumTgts + NumTgtsInBand; 
Ena, {Fer} 


TotTgts[Tgt] := TempSumTgts; 

Read (SiminFiles,; Tothlts); 

Read (SimInFile3, BdaProb[Tgt]); 

Read (SimInFile3, RepTime[Tgt]); 

ReadLn (SimInFile3, RepProp[Tgt]); 
End; {While} 


Kee eee 


Read in simulation specific data from "sim2in.dat”. 
kek kk kek kk 


ReadLn (SimInFilel, TvdWgt, GoalWgt); 
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ReadLn (SimInFile1l, NumPeriods, NumDays); 
ReadLn (SimInFilel, NumAcftTypes) ; 

For Acft := 1 To NumAcftTypes Do 

Begin 


ReadLn (SimInFilel, AcftType[Acft]), NumAcft [AcftType[Acft]], MaxLoss[AcftType[Acft]], 


SortieRate [AcftType[Acft]]); {** Note 1-7 
BM; Or } 
ReadLn (SimInFilel, NumTgtClasses); 
For Class := 1 To NumTgtClasses Do 
Begin 
Read (SimInFilel, Temp1); 
For Pd := 1 To NumPeriods Do 


Begin 
Read (SimInFilel, Goal[Class,Pd]); 
End;  (Eor} 
ReadLn (SimInFilel); 
End; {For} 
For Class := 1 To NumIgtCilasses Do 
Begin 
Read (SimInFilel, Temp1); 
For Pd := 1 To NumPeriods Do 
Begin 
Read (SimInFilel, Ppen[Class,Pd}); 
Bnds) {for} 
ReadLn (SimInFilel); 
End? {For} 
For Class := 1 To NumTgtClasses Do 
Begin 
Read (SimInFilei, Temp1); 
Tgt == 0; 
While (Not (SeekEoln(SimInFilel))) Do 
Begin 


Tt ecm eeha c+ 
Read (SimInFilel, TgtClassTgt (Class,Tgt]); 
End; {While} 
TgtsInClass[(Class] := Tgt; 
ReadLn (SimInFilel); 
End; {For} 


ae ke te ke ke ke kk ke 


Start replication loop; begin reading data from "tsvtst.dat"” and run simulation. 
ete ete ke kk kkk 


Sumv := 0.0; 
SumX1 := 0.0; 
SumX2 := 0.0; 


kkk kkk kek ke 


If you do not want the objective function value for each replication output to the 
output file in tabular format, comment out the next line. If you want it in tabular 
format, don’t comment it out, but then you must also choose the 2nd method of the two 
presented further below of outputting the replication and obj fen value (see imbedded 


comments below). 
Pa a a a ae 


Weitelne(Simoutei le, ““Replication”’,",;*,'"0bj Fen Val”*)3) 
For I := 1 To NUMBERREPS Do 
Begin 


Se ie ed 


Next If..Then is *** debug ***. These are the column headings for the major output 


statistics output showing the results of a particular replication simulation run. 
keke kkk wet 


If ((I = REPOUT1) Or (I = REPOUT2) Or (I = REPOUT3)) Then 


Begin 
Tt Olsaer ea her 
Begin 
WriteLn (SimOutFile); 
End; 


WriLtsin-“(SimOut bate aanepiicaciom -, >; 5 "“Period™"*{"7 3. Alirerate... 
UEVALQGU lcs nee aS Sees PM” go a NA DOLL af gg eke pg a, 


TeSorties”’) To aeetoUSorlieselown” °°; ">", *"SortieRate*”,',.',  "“MaxLoss”™'. *) 


ITACERLOSL( 1. eee mGOa 4 “Propki lied”. "5 = Pro, op, 
PRC" a Gs CE eee evel >) DeaAGN” 'y.°,"*;,*"Regenn™* 3. 0%, 
“OLIVER 5 abe aelaars aay an, *"RegenR"', ge ei Lie She nese 
"Wdeltalgtskilledt 3. -1gtsbeadOrinRepair”',",*, “lgtVal” a, > 
Yedeltalvor 7. oe 
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Ena ey 
Reset (SimInFile4); 
Shee I anaes 
?va == 0.0; 
For Acft := 1 To NumAcftTypes Do 
Begin 
AcftLost [AcftType[Acft]] := 0; 
End; {For} 
For Igt -= i To NumiqtTypes Do 
Begin 
LiveN(Tgt]) := TotTgts[Tgt}; 
DeadN[Tgt] := 0; 


RegenN[Tgt} := 0; 
LiveRlTge} 3— 0; 
DeadR[Tgt] := 0; 
RegenR[Tgt] := 0; 
For Pd := 1 To NumPeriods Do 
Begin 
PALftrt (tat, Pd} :— so; 
TgtsDeadOrInRepair[Tgt,Pd} := 0; 
End; {For} 
Ends {For} 
While (Not (SeekEof (SimInFile4))) Do 
Begin 
For DataValRead := 1 To 12 Do {** Note 2 **} 
Begin 


Read (SimInFile4, Ch); 
While (Ch <> ',') Do 
Begin 
St := St + Ch; 
Read (SimInFile4, Ch); 
End; {While} 
GetRealNumber (St, Number); 
Case DataValRead Of {** Note 2 **} 
2: Pd := Trunc (Number); 


4: Acft := Trunc(Number); 
6: Tgt := Trunc (Number); 
9: Eks := Number; 


10: Nabort := Number; 
11: Attr := Number; 
12: x := Number 
Else 
Templ := Number; {** Note 2 **} 
End; {Case} 
Sus= = 
End; {For} 
Class := GetTargetClass (Tgt, TgtClassTgt, TgtsInClass, NumTgtClasses); 
TempTvd := 0.0; 

BeforeTgtsDeadOrInRepair := DeadN[Tgt];} {** debug alternative to next line **} 
BeforeTgtsDeadOrInRepair := DeadN[Tgt] + RegenN[Tgt] + DeadR[Tgt]) + RegenR[Tgt}; 
deltaTgtsKilled := 0; 

TotSortiesFlown := 0; {** Data purposes only **} 
Pees= RepPropl ict]; 

NPr := 1 — Pr; 

Peres io Exp{-(i / Replimei iat ]))); 

NEC. = ie) Po: 


kkk kkk kkk e 


If you want to test the case of perfect BDA, i.e., no restrikes will occur, then remove 
comments from next line and comment out the line after next. If you choose perfect BDA 
for the B probability assignment here, you must also choose the same option for the NB 


probability immediately following the B probability assignment code lines. 
ste te ke te ke ke ok ke ok te 


Be = 1.07 }) o> Pertect™ BDA **} 
B := BdaProb(Tgt]? {** Imperfect BDA **} 


kk kk kkk ek ke 


If you chose to test the case of perfect BDA, then remove comments from next line and 


comment out the line after next. 
eek kkk kkk kk 


NB := 0.0;} {** Perfect BDA **} 
NB := 1- Bz; {** Imperfect BDA **} 
RunSimulation (NumDays, NumAcft[Acft], MaxLoss[Acft], SortieRate[Acft], 
AcftLost [Acft], TotTgts[Tgt]), TgtVal[{Tgt,Pd}], Goal[Class, Pd], 
Eks,» Nabort, Attr, x, TotSortiesFlown, Pr, Nr, Fe, NEc, BE, Ne, 
LiveN[Tgt], DeadN[Tgt], RegenN[Tgt}, LiveR[Tgt], DeadR[Tgt], 
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RegenR[Tgt}, deltaTgtsKilled, TempTvd); 
Tvd := Tvd + TempTvd; 
TgtsDeadOrInRepair(Tgt,Pd] := TgtsDeadOrInRepair{Tgt,Pd] + ((DeadN[(Tgt] + 
RegenN[(Tgt] + DeadR[Tgt] + RegenR[Tgt}) - 
BeforeTgtsDeadOrInRepair); 
PropKilled := DeadN[Tgt] / TotTgts[Tgt];} {** debug alternative to next line **} 
PropKilled := (DeadN[Tgt] + RegenN[Tgt] + DeadR[Tgt} + RegenR[Tgt]) / 
TotTgts(Tgt]; {*** debug ***} 


eek ke dk ek ek 


Next If..Then is *** debug ***. These are the major output statistics showing the 


results of a particular replication simulation run. 
tee te tee ke ee 


If ((1I = REPOUT1) Or (I = REPOUT2) Or (I = REPOUT3)) Then 
Begin 
WELCehLn a oimMeere al Po, ", ACEt, “7 7 loth, °,Class," ,",;Eks:9<4.".', 
NapoGeewes, 5 ~ACEr 94," ; "x24, ", > LOtCSOre1esklown,”; 
SOuULTeRAEe|ACEE) 29:4, ,",;MaxLoss(Actt],", pAcEtLLOset (AcEE],* ,", 
Goalrelass, Pd) :924,°,°, Propkiiled:3:4,° 5 ~Prage4, 2 7 Pec :o:4,) 
Bui, 7; LiveN(Igt)],",°, DeadNiTge),', ,RegenniTgt], "3", 
Iavek(Tgt),',',dDeadR(Tgt],*.*°-RegenRIiTgti.'. ,lotigtsligtl.', ", 
deltaTgtsKilled,',‘,TgtsDeadOrInRepair([Tgt,Pd],°,*,TgtVal[Tgt, Pd] :9:4,',' 
Tenpivoso.a; ¢' ¢lVato: 4); 
End; {If} 
Stoc= t*s 
ReadLn (SimInFile4); 
End; {While (Not (SeekEof (SimInFile4)))} 


ee ee dd 


Next If..Then is *** debug ***. This just outputs a blank line to seperate blocks of 
output data in the output file. 


keke ke kkk kkk 


Pfiet(l = REPOUT!) Or (1 = REPOUTZ) Or (I = REPOUT3)) Then 
Begin 
WriteLn (SimOutFile); 
End; {If} 
GetPdiffValues (NumPeriods, NumTgtTypes, NumTgtClasses, TgtsDeadOrInRepair, TotTgts, 
TgtClassTgt, TgtsInClass, Goal, Pdiff); 


ete et kk kk ke 


Next If..Then is *** debug ***. This outputs the pdiff values for each target type by 
period. 


keke kkk ke 


If ((I = REPOUT1) Or (I = REPOUT2) Or (I = REPOUT3)) Then 
Begin 
Writein (SimOutFile," "Period" ";', ,’* "Target"; °; +7 eeibee.)s 
For P := 1 To NumPeriods Do 


Begin 
For T := 1 To NumTgtTypes Do 
Begin 

ieeaLne ColmOuth le, Pio 1, ghObelill,ae ls os4) 

End; 

End; 

WriteLn (SimOutFile); 

Ends “1 15) 


Temp2 := CalculateObjFcnValue (NumPeriods, NumTgtTypes, NumTgtClasses, TgtClassTgt, 
TgtsInClass, Tvd, Ppen, Pdiff, TvdWgt, GoalWgt); 

Sumv := Sumv + Temp2; 

SumX1l := SumX1 + Sqr(Temp2); 

SumX2 := SumXZ + Temp2; 


kankke ete 


If you do not want the objective function value for each replication output to the 
output file, comment out the 2 WriteLn statements in the next If..Then. Otherwise, 
choose one based on your preferred method of having it output, but only choose the 2nd 
one if you chose to leave in the tabular format for the output from above. 


Se a a i a ee 


Tf (1 <= 100) Then {*"> Note 52*+} 
Begin 
Writein (SimOutkFile;* "Repltesarions 55. , 15.5... Objkenval: 4. 2.- lenpe 15:4); 
WriteLn (SimOutFile, 1, >, lempzsGo 4) 
Ends. <1f] 
End; {For replication loop} 
v 3:= Sumv / NUMBERREPS; 
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If (NUMBERREPS >= 30) Then {** Note 4 **} 
Begin 
StdDev := Sqrt((SumX1 - (Sqr(SumX2) / NUMBERREPS)) / (NUMBERREPS ~ 1)); 
Ends). {If} 
Writein (SimOutFile); {¢*** debug ***} 
Writeln (SimOutFile); {*** debug ***} 


hte te tek te te ee oe 


Pick one of the next two statements to output the number of replications. Pick the 
first one if you want to output to the screen only, pick the second one if you want to 


output to the output file, then comment the other one out. 
Keke dk keke 


{ WriteLn ('Number of Replications: ‘',NUMBERREPS) ; } 
WriteLn (SimOutFile, *"Number”'’,',', '"of"‘,',',""Replications: ™',','*,NUMBERREPS) ; 
WriteLn (SimOutFile); 


Se de a a 


Pick one of the next two statements to output the objective function value. Pick the 
first one if you want to output to the screen only, pick the second one if you want to 


output to the output file, then comment the other one out. 
kkk ek kk kkk 


{ WriteLn ('Objective Function Value (v: weighted sum of TVD): ‘°,v:15:4);} 
haeeoln  (SImouteile,  "“Opyectave "9, , "Function" 7", ',° "Value" ",",','°°(v 2e%7'," 
I"#welqhted@. .. "sum ee, fog Dg pn op Ve Los) ¢ 
WriteLn (SimOutFile) ; 


Se A de i ed 


Pick one of the two Writeln statements in the following If..Then to output the standard 
deviation. Pick the first one if you want to output to the screen only, pick the second 


one if you want to output to the output file, then comment the other one out. 
Kk ek a ke 


If (NUMBERREPS >= 30) Then {** Note 4 **} 
Begin 
{ WriteLn ('Standard Deviation: ‘',StdDev:15:4);} 
Weitoln (SamOuthite;’ “Standard ‘2°. * "Deviation e. 9 ws ~ocaLvev: 1524) > 
Bids {if} 


ek ek kk ke kk 


If you are NOT sending output to the output file, comment out the following For loop. 


eke tet te ke ke kk 


For i 4= 1 To 50 Do 
Begin 
WriteLn (SimOutFile); 

End; {For} (2 sNoOLe (482s 4 
Close (SimInFilel); 

Close (SimInFile2); 

Close (SimInFile3); 

Close (SimInFile4); 

Close (SimOutFile); 

End. {Main Program} 
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The following is the data file “sim2in.dat” used by SimStrike. The format must 
remain exactly as shown below, however, the data may change of course, but must be 
representative of the items explained below. Note: Do not include the comments in “{}” 
shown in the listing below. These are merely for explanatory purposes within this 
Appendix only. They do not exist in the actual file, nor should they be included. 


920) -1.0 {TVDWGT, GOALWGT } 
5 12 {no. of periods, no. of days in each period} 
9 {no. of aircraft types which will actually be flying sorties} 


iNext 9 lines =(pecause there are 9 aireratt types actually flying 

orties in this case) are in the following data format: 

aircraft type, no. of aircraft type starting, max. loss allowed for this 
aircraft type, sortie rate (sorties per aircraft per day) for this 
aircraft type} 


Ih 96 8 1.48 

2 AZ 4 6 

3 16 al .6 

4 2 il “6 

6 36 Z ae 

7 OZ 8 1.09 

8 129 iT dene 

9 GS g SES), 

10 a2 4 48 

10 {number of target classes} 


{Next 10 lines (10 target classes) are in the following data format: 
target class, proportion of targets in target class to be killed to 
achieve the kill goal for each time period up to the number of periods 
over which SimStrike is to be run} 


J) 4 oo mal 120 iS) 
Z 30 ZO AL, ie 0 
3 ie) ili, eae uel, ie 
3 se oS 0 IG Ibe. 
5 8 SNe, ree 120 Ie 
6 IANS) 120 leo) eo 0 
7 Os 4 i ee. iO dee, 
8 22 oS, = IA 0 
S 0 reo iO Ib I 0 
10 -4 4 ie Ae! ake 


{Next 10 lines (10 target classes) are in the following data format: 
target class, objective function penalty for not meeting the time- 
scripted kill goal for the target class by the end of the period for 
each period} 


a 64 64 Is 16 64 
Z IG 16 64 64 Is 
is i! il ih 1 1 

4 16 ims) eG io 16 
5 64 64 64 64 64 
6 64 64 16 16 4 

y 4 5 04 64 64 
8 i it il il 16 
2 t 4 64 64 16 
10 16 16 16 16 16 


{Next 10 lines (10 target classes) are in the following data format: 
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target class, listing of targets which belong to the target class (this 
is known as target class-target correspondence in TIME STRIKE) } 
owen?) 19937 s3ceci 6m 66.69.70 76 

Peas 2Oe2 leo Ieo0 3256 39 4) 42 46 60 62 63 64 67 68 74 75 
Sip! Css sia si eameys! 

a3 4 556 7 10 Liei2 28 47 48 71 72 

Seco 50 5). 77 78 

6 22 26 54 

we 25 24 

8 913 27 31 40 43 44 45 59 73 

S33 34 35 

fumes 52 53 7/9 80 8 G2 83 84 85 86 87 


This is the end of the file “sim2in.dat”. Do not leave any blank lines at the end of 
the file, except for one position for the end-of-file marker. As long as the copy of this 
file provided with the original form of SimStrike is used as a template for changing the 
data contained in it, errors can be prevented. 


a5 





APPENDIX B: SAMPLE OUTPUT 


The sample output on the following pages 1s the result of a run of SimStrike using 
the model data set provided by Maj. Kirk Yost, USAF, as mentioned in Chapter II. It is 
the exact output produced by the program listing in Appendix A. One-thousand 
replications were done, with only one-hundred objective function results shown so the 
output file would be limited in size so as not to present problems when opening in the 
editor of a spreadsheet application (this is also eluded to in the comments within the 
program listing). The final results are on the last page of the sample output. 

A detailed replication instance is shown for replication number one. The column 
headings for the most part are the same name as the variable they represent in SimStrike. 
In any event, the headings are self-explanatory as to what statistic they represent. These 
headings can be more easily understood, however, if the corresponding variable 
definitions in the comments just prior to the main program part of SimStrike are referred 
to. 

Also, as mentioned in Appendix A, this output can be modified to take different 
forms based on the preference of the user. Please refer to the comments imbedded in the 
main program part of the program listing to change the output format as desired. 
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724} Replication. | | OtprcnVattan | 40s(ere 900) ee ee ee ee 
[T25iReptication | 81/OpFenVal: | aiz72ze 146] tess! 
727|Replication | BS ObjFcnVal_— | 4150923018; ||| ee 
‘T2miRepiicabon | B4)ObFenval: | 4052817.272; | CTT 
729) 2S ee Saas ee Seen eee Pi Paes eee 
TsQRepiicabon:| — BB|ObjFenVal. | 3987224724; ||P 
733{Repiicaton | 89/ObjFenval | 40esisoss} | Tt 
TaaRepiicapon: | 90 ObjFenval. {| 401050123} | 
WagiRetremion: | 81\Oorcnvat, | 4152952.787| ee ed ea 
7ae{Replication | 92/ObFenval. | 4131853.078; TT 
[7a7|Rephcaton.| ___93|ObjFenval__| 2e18ss7.241, || ||. |.-+|~-+4| || |__| 
meARepmcaton | «PS Onjrenvar | a0esezacsa| | LCC ee ee Gd 
BE ES Pe =) NT eT) ST AT PL DL ee ee 
741 
Rephcation:| —— 9B|ObFenVal. [| 4104s3e.sas} | TT 
7aa|Replication | _—100|ObjFenval. | 4012412651; | || eee 
7 (= | | th = |i ae | ee fl ee | 
ee eo eee ee eee ES 
[747}Number_ [ot | Replication: 1) nn en en 
Praa|Objective_[Functon [Value |iv___—_—_—(iweighted| sum of |Tvb)_| aotoseosi2| [TT TC 
Do 2 Sill Ee ee eee eee eee ee Oe eee 
ToilGtandard = |Davation: |\m24S0201224)cemeen jen ee) le | ee ee | | | 
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